PSA to anyone stumbling on to this thread.
I've confirmed a bug with support introduced somewhere in 8.1 that will break find and replace if you use the word "Arguments" in your doc string (triple speech marks).
Apparently this clashes with the inbuild Ignition function documentation and confuses the parser.
So avoid using that like i did, and stick to the shorter version of "Args"... 
Now to find all the places i've done it amongst hundreds of windows..
The good news is that it only affects Vision extension functions in particular. A bad choice when we first introduced their serialization that was basically unavoidable when extracting them back out again to upgrade, unfortunately.
Will it still be a problem if there is another def block inside the main extension function?
Like this for example?
No. Only a triple-double-quoted bare string, on the very first line, containing the literal string Arguments: will cause the issue. Break any of those conditions and you're fine.
Docstrings per Google style
It will be amazing if you clould add a context menu on right click on function to generate this docstrings template !
Note: Any really big stuff will have to wait until after 8.3.0, so don't expect a lot on this topic for a while. But, a dependency bump in the bundled library did get a few little niceties I think you'll all appreciate; these will be in the nightly tomorrow and in 8.1.38 full:
Yay!
This is awesome!
--runs to recommend upgrade solely for this function--
I actually did just that after reading the patch note !
I do this all the time in PyCharm because of this haha
Looking forward to upgrading! In a few years' time, knowing our end users 
yes please! that looks mint
Are there any plans to autocomplete imported java libraries that are not 'system.' or self written scripts?
Eventually, maybe.
Two big complications:
The first, understanding import statements requires a constant AST parse of your local code (which will often be syntactically wrong for some amount of time), so you have to do smart caching and best effort stuff. Not at all impossible; every IDE does it, but it's a big effort.
The second: Java reflection gives you a lot at runtime, but it's really not as useful as you might hope. You can get arguments, return types, exceptions, etc - but no argument names, no method or class documentation, etc. You'd also have to constantly round trip with the gateway to ask it for reflection information on any gateway scoped imports, since they won't be available to the designer.
Or they could, you know, add a button for it so people do not have to use mind reading or random key sequence testing.
Ctrl + / is not exactly random. It's a common, almost ubiquitous, shortcut used for commenting out large sections of code. Try it in other places such as just about any SQL management tool or IDE, and I'll bet that it works in most of those places too.
One thing my old eyes would appreciate is instead of the teeny tiny red bar on the right, do a light red highlight of lines with errors?
Like highlight the entire line vs just the little red thingy on the right 
I'm not sure if its just me, but I feel that often the red bar on the right doesn't actually indicate the correct line of code that has the problem?
I've noticed it moves around as you scroll sometimes which makes troubleshooting difficult.
Agree that highlighting the actual line with syntax error in question would be great.
