This is "fixed" for 8.1.19/the next nightly; you will no longer get an incorrect autocompletion for the (builtin) format method that looks like it's a string instance autocompletion. You will not get string instance autocompletion, unfortunately, but smarter 'local' autocompletion is probably the next item I'd like to address.
The inner problem that causes this is now caught, so if the fold parsing logic breaks, you won't get any folds, but everything else will still work. A fix for the fold parsing logic will hopefully come soon.
And yes, project library autocompletion throughout the designer.
As a small bonus convenience feature, we also added an option to select which hint scope to provide for autocompletion while authoring project library scripts:
This setting will persist with your script library, but does not affect actual execution in any way; it's just a convenience to help with script authoring.
I have an immediate knee-jerk aversion to that (since itās essentially exec, but in the context of your gateway), but at the same time, itās not appreciably different/more risky from what you can already do in the designer (e.g. Perspective, gateway event scripts, tag event scripts), so I canāt really articulate a good reason not to do it . I do worry that it will only further confuse some folks, since Ignitionās split scripting environments are already a bit of a nightmare, but it may be something to consider.
Gateway message handlers can be used to perform such testing, but require understanding of what executes where. That is a clear win, I think. If one doesn't understand the scope model, one cannot easily do damage in the gateway.
This would be my exact use case, debugging/developing gateway event scripts. The gateway context is running under a different service account and has access to differing LANs, currently debugging of these scripts can be difficult in some cases as it takes some extra work to setup properly to run them the same way they would execute in the gateway script. It can be done today, but it could be easier.
Reaching parity with VSCode is definitely not a goal (nor is it feasible, for obvious reasons). However, bundling VSCode is also not feasible. I would like to see a system in the future where external code editors are supported, but making the core product better is an obviously good step in the short term.
Yes, there's still no true AST parsing of the file you're currently editing (because it's a hard problem, since you could have any number of syntax errors). With project library stuff, it's relatively easy to consume, because in the vast majority of cases a project lib file you're not actively editing will be valid code. This is something I'm planning to work on, but no timeline; that would be the next big leap in capability for the script editing system.
Thereās a lot to like about the inline search feature in 2.1.18, but Iāve run into a couple of issues with it.
First, F3 no longer seems to work as a ārepeat searchā command. The ability to do this with a single keypress rather than hunt for and click the little down-chevron is much missed.
Second, it would be nice if performing the search would put input focus back into the editor, rather than leaving it in the search field. I also havenāt found a way to move focus back without using the mouse.
I have discovered a little bit of a workaround to the issue with the missing functions on the right side of the Designer. When you open a script, if you do a Ctrl+A to select everything and then Ctrl+/ to comment out everything, the functions all appear on the right hand side after about 1 second. Then just hit Ctrl+/ again to uncomment everything, and the functions are still visible on the right side.
Just wondering about this one (project class/function 'intellisense') so that I can prepare for when this is out. This might be obvious to someone from a software dev background, but for us other plebs...
What is the best structure to follow in the doc strings to document library functions & classes so that it will work nicely with this functionality?
Some specific questions:
how should I document the return value?
how should I document the arguments of a function?
The PEP standards don't seem to cover this... unless I've just missed it?
I tend to do what I think is googles style but an example of something that works currnetly in 8.1.3 in script console
def exampleFunc(someNum):
"""
Some small description of what the function does here.
Args:
someNum: int, this gets a 1 added to it
Returns:
int, the param with a 1 added to it
"""
return someNum + 1
This doc string method currently works in script console going even using 8.1.3 - an example from a current project (though black text on a dark background - any way to change this?)
I do believe python expects that if thereās triple quotes immediately right after function declaration that its expected to be the docstring of the function and hence why Ignition is able to pick this up even before all these very nice improvements. I expect it will stay the same way though perhaps they will also offer an alternative to the triple quote method immediately after a function declaration.
If I can get this working at some point in the future, the way to do proper type-hints would be the suggested syntax for PEP-484 in Python 2: PEP 484 ā Type Hints | peps.python.org
In the meantime, yes, all this does is pick up the docstring (first string expression following a declaration). Thereās some trickery involving class bodies and __init__ methods, but other than that itās fairly straightforward.
That's planned, but may have to wait for 8.2 for the sake of API compatibility for third party module authors.
At some point, local AST parsing might be able to use reflection to offer limited autocomplete for local Java libraries. It probably won't ever work across scope boundaries, so there won't be any hints offered if you're in a Perspective or other gateway scope.
Of course for both of these scenarios one may use ignition-api (PyCharm and Visual Studio Code) and/or ignition-api-stubs (PyCharm).
Both will provide autocompletion for the constants under db, gui, and serial, as well as some (not all) com.inductiveautomation.* classes and other supporting Java libraries.
. I do worry that it will only further confuse some folks, since Ignitionās split scripting environments are already a bit of a nightmare, but it may be something to consider.
