Coming in 8.1.18: Script editor improvements

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.

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

3 Likes

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.

@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.

1 Like

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.

1 Like

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! :slight_smile: thanks for adding it!

10 Likes

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

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

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

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

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

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

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

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

1 Like

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?

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.

3 Likes

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

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.

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 :sweat_smile:

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

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.

7 Likes

Thanks for the explanation @PGriffith :slight_smile: 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 :smiley:

1 Like