It's been discussed. Exceedingly non-trivial, and not going to happen any time soon.
{ Much more likely to be PyCharm than VSCode, due to the java underpinnings, which pleases me. PyCharm, while commercial, is published by a company with a long history of ethical conduct. VSCode, while currently open-source, is published by company with a long history of the opposite. I, for one, refuse to use VSCode--I don't want to be caught by the third "E" in "Embrace, Extend, Extinguish". Been there, suffered that, have the coffee mug:
I still use Visual Studio on a somewhat regular basis because I have several C# apps that I support, and I read somewhere a couple of years ago that "they" were going to be dabbling more in Java, but I haven't seen anything yet that I would use for Ignition.
I have a subscription to MS Visual Studio itself, because there are a few things I might need to take care of that require it. So, no worries if you need it. You (and I) are already captured for those cases.
It's the voluntary submission to future abuse that I refuse to accept.
Yeah I can respect that @pturmel. While it may be non trivial to do a full implementation, it would be pretty easy to add a 'open in VSCode/PyCharm' button which would open the exact same code in the IDE, and add a keyboard shortcut in the IDE that would execute the script in the ignition script console. Rn I'm copy pasting between the 2 because I need version control and like the proper formatting and github copilot I get in vscode.
Sure, that part's easy enough. But how about system function autocomplete? And project library? And dealing with the different execution scopes in Ignition?
Also, conceptually, it's a bigger hurdle than it seems. Right now the ultimate source of truth for a project in the designer is the designer/the designer's memory model. To open in VSCode/etc, we'd have to write out scripts (in what format? What about the extension function preamble?) to disk (where? temporary files?), launch or otherwise communicate with the external code editor, then either communicate with it bidirectionally via LSP or watch the filesystem for changes - and then the question arises of what to do in a conflict between the filesystem and the memory model?
None of those questions are unsolvable and it's absolutely on our/my radar... but it's also definitely not as trivial as "invoke vscode.exe path/to/myScript.py and you're done".
yeah that sounds hard, just do the easy bit and move on, 80/20 style. all i want are git/github/version control, github copilot, proper formatting, and nightmode, and i think you can get all of that with the quick and dirty solution. put it in a beta release and i promise i'll test it
Of course, as said before it's been discussed many times.
And as said before, even the simplest solution you can think of has implications that make it non-trivial.
There's no "easy bit".
There's been a lot of improvements to the editor already, Paul (?) is doing a tremendous job on this.
Trust him to do what he can to make your experience better. But he's not a magician.
