Coming in 8.1.18: Script editor improvements

This is fixed for 8.1.19/the next nightly build.

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.


What would be really awesome is if you had some type of option to make the script console execute in gateway scope.

Barring that any chance we could get this same option on the script console?


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 :slight_smile:. 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.

1 Like

With you. Don’t do it.

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.

1 Like

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.


What about having a set of “Required Designer Roles” for gateway scope execution?

1 Like

This is awesome!!

IMO, so much work would be required to reach the featureset and quality of something like VSCode, and VSCode already exists and is free to use.

The work that César Román has done in his repository could be coupled with VSCode as the ‘standard’ for scripting in IA.

Then the development and maintenance of the inbuilt IDE is no longer required. Freeing up resources to work on other bugs and features.

1 Like


New release for the script editor in 8.1.19 nightly is really awesome ! :star_struck:

A few minor possible improvements:

  • functions inside a script are not available for autocompletion if you don’t add the package name.
  • an option to sort the function list in alphabetic order or the file order.
  • some keyboard shortcut for Find Previous/Find Next
  • right mouse click on function to generate docstrings
  • blue mark for # TODO: IntelliJ like :wink:

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.

1 Like

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:

  1. how should I document the return value?
  2. 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.
        someNum: int, this gets a 1 added to it
        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.

Some examples - Example Google Style Python Docstrings — napoleon 0.7 documentation


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 |

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.


Maybe I’m missing something, but is there any way to easily add the optional method parameters when it auto completes?

I still have to go back and forth to see what optional parameters a method takes

1 Like

Here’s a feature request.

When we type system.db. we only get the list of functions. My request is to also list the constants.

Same for system.gui, system.serial constants, and all other I am not listing.

1 Like

And if I may.

What about com.inductiveautomation.* and other Java libraries?

Thanks again

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.

1 Like

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.

Had I mentioned this before? :stuck_out_tongue_closed_eyes: