Coming in 8.1.18: Script editor improvements

[scottmwyant]

Re: @Bradley_Phillips on June 1st, comment 12.

Came here to say this!

Big fan of VS Code here. With all the work being done in VSCode + extensions, I feel I’ll always be disappointed by the designer editor.

That’s not meant to be a knock on IA team, I just think they have bigger fish to fry and the number of total hours spent developing VS Code (including community extensions) is probably staggering.

I wanted to point out that VS Code does have a remote development mode. Perhaps that technology could be used to edit scripts on the gateway? I really don’t know what the architecture for that would even look like. Just throwing it out there. Probably a IA backed extension for VSCode??

I’d pitch this as a way to give Ignition users a rich script editing experience that would probably even take some work off the IA team.

Visual Studio Code Remote Development

@PGriffith, anyone ever think of this kind of approach?

[kgamble]

@PGriffith

I would love to make the designer an LSP client, which would allow offloading a lot of tasks to external editors; but to do that we’d have to push designer-local resources to disk somewhere, and there’s some tricky complications there.

Similar complications exist for pushing files to disk and opening in external editors; in addition, opening an external editor such as VS Code wouldn’t work perfectly without some doing because: 1. you wouldn’t have your project scripts in the right spots, and 2. you wouldn’t have autocompletion for any system functions, and 3. you wouldn’t have autocompletion for any Java libraries.
Doing that properly might require the designer acting as an LSP server, which is also a big task.

Here is a technical answer to how it would be done, though it doesn’t really call out if it’s on the docket. I would have to assume it’s sadly pretty far out. We are talking about practices that are likely the future of the product, but the team at IA are probably focused on the problems of today before that of tomorrow. Don’t get me wrong, this type of feature would revolutionize the platform, and I would be the first to adopt it. However It’s probably a ways out, unless there are some
Module dev gurus willing to take on the challenge of making this a module feature, if a module can even handle it.

[PGriffith]

@PGriffith

@Bradley_Phillips

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.

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.

@scottmwyant; see my post higher in this thread. There's a lot of technical hurdles to giving external editors access to scripting. You can sort of do it right now, with the project library, but the way other areas of Ignition 'bundle' scripts into arbitrary resources is the main problem with attempting to edit other areas. Getting an external editor to 'understand' all the context of an Ignition scripting environment (and giving it access to bidirectionally update text in a script) is a big hurdle. That's why I mention making the designer an LSP client; then it's a lot easier to 'offload' autocomplete work to external programs that have all that time invested.

Definitely something we're thinking about into the future, though.

[Dan_Bridgeman]

@Alex_Taylor

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.

Agreed on all of the above. I do like the ability to modify the search string and to use regular expressions, but having to keep going back and forth between mouse and keyboard slows things down significantly.

[nminchin]

I just wanted to say that the addition of “intellisense” of user script library functions is incredibly useful! It’s a very nice creature comfort to have! thanks for adding it!

[mazeyrat]

Yes Big up to @PGriffith and the IA team for this great feature !

There is still a few room for small improvments…shortcuts, function comment generator, function list sort option, etc

[louagejasper]

A ctrl-shift-arrowdown shortcut for copying lines would also be nice. It's so useful in vscode, makes copying lines so fast!

[PGriffith]

Ctrl + D will duplicate the current line; that might be the same as what you're looking for?

Rebinding of keyboard shortcuts is a thing we'd really like to add

[louagejasper]

For me, ctrl-d removes the current line . Is there a documentation of all the current bindings?

[PGriffith]

What version of Ignition are you using? Ctrl + D would delete in the older editor, but is duplicate in the new one.

[bkarabinchak.psi]

You can put this as the very last item on the wish list but since we are talking about key bindings, a way to enable vim key bindings would be cool

[louagejasper]

I was testing this on 8.1.18, but I see on 8.1.21 it does work, great!

[Christian_de_Bellefe]

It's not working for me too.

Windows 11, French Canada QWERTY Keyboard.

When i press CTRL-/, it just collapse Every indentation. This is one of the most annoying problem i've found in Ignition. The 1st major irritant i've about Ignition is that when i press ESC when a popup is shown in the designer, i expect it to Cancel this popup. Windows and many other OS are built like this since ages...

[bkarabinchak.psi]

Any chance we could put a property selector on the script editor? I like to do all my scripting in script editor like my buttons action buttons are usually something like myLibrary.submit(event) but this means normally I have to do my property selectors in the button script window, then copy them over to my project library script. It'd be nice if there was the ability in the script editor to pick a window I want to pick a property from and then pick a property off that component and get the event.source.path.to.my.prop. Would this be possible?

[PGriffith]

Hmm. That would get complicated fast (e.g. Vision, Perspective, alarm pipelines, SFCs, reporting all have their own "selectors" they would potentially want to contribute).

I feel like a better paradigm might be more flexible editing of project library scripts from anywhere in the designer. Though that still sort of has the same problem, unless the project lib editor you open is contextualized somehow by the local editor...

I'll have to think about it. I can definitely see the pain point.

[kgamble]

We typically put entire transform scripts inside project scripts, just due to them being stored as Python files.

Would be great if through some behind the scenes magic those transforms got stored and edited similarly to project scripts, would solve the whole context of params being passed through.

Obviously a harder ask though

[bkarabinchak.psi]

Yea not sure what the best way to handle it would be, but it is certainly a bit of an annoyance. I think a floating script editor that you can open wherever could be the right solution here.

[matthew.ayre]

@PGriffith

There’s some trickery involving class bodies and __init__ methods, but other than that it’s fairly straightforward.

Sorry to drag up an old topic, but I'm struggling to get class body docstrings to work. I can see in the IA manual that class documentation ("Autocomplete hints will also display docstrings for user-written functions.") is not explicitly mentioned and wondered if it's supported?

As you mentioned some 'trickery' involved, could you elaborate further? I'm sure I'm missing something obvious

[PGriffith]

Ah, I bet I know the problem.

Is your class a 'new style' class, that properly inherits from object? As in:
class MyClass(object):? The current detection for the docstring relies on the first AST node after the class entry being a string literal, but evidently I forgot about inheritance in my unit tests .

The "trickery" I alluded to was just that there's a preference to give you the hint for the __init__ method over the class description, since you're (usually) constructing a class vs referring to what it is. Improving the contextual nature of these hints is also on the list of planned improvements.

So, you can see a class with no superclass and no init method does hint the class docstring:

But if your class has any superclass(es), the class method isn't available, and so it tries to hint the init method:

And if you have a specifically defined init method docstring, that will always be preferred:

I'll make a note to improve the class body docstring parsing; I'm already planning to revisit the parsing here in the next few weeks to add parsing for Google-format docstrings.

[matthew.ayre]

Thanks for the explanation @PGriffith you hit the nail on the head. As others have echoed, the script editor improvements have been an excellent addition, looking forward to seeing the next pass