Visual Studio Code Extension currently available and future plans for SciTE?

[Jos]

All,

I see that there are multiple efforts to create/maintain an AutoIt3 Visual Studio Code extension, and I would like to open a discussion to see how that can be streamlined/merged/done more effectively so we can come up with the one that's preferred.

I have been toying with the idea to stop the development of all the LUA extra's used by SciTE and start using VSCode for the more advanced way of developing AutoIt3 scripts, as many things a way after when the extension supports it, like running au3check on save so you just click the problems tab to see the warnings/errors of the currently opened scripts.

So I have been working on making the utilities packaged with SciTE4AutoIt3 suitable to run stand-alone without the need for wrapping them with AutoIt3Wrapper, with the plan to be able to make them all more generic usable for any editor. They need to support UTF8 & ANSI encoded files, even when through includes the encoding is mixed. 
I have modified AutoIt3Wrapper to stop renaming and changing encoding of script/include files, and updated Tidy/Au3check/Au3stripper to support special characters in filenames and mixed ANSI/UTF8 file encoding and the generated console output is UTF8.

I have been toying a bit with the VSCODE extension maintained by Damian (just picked one without looking at any others) and made some modifications locally for testing. Run au3check (Ctrl+F5), Tidy (Ctrl+t),  Au3Stripper (Ctrl+Shift+o)  without using AutoIt3Wrapper.
Other already standardly available option (Run/Compile) still run via AutoIt3Wrapper as there is an added value doing it that way.

I really like what I see and think this is a good way forward.

So...  I like to hear how you all think about this and possibly your preferred VSCode autoIt3 extension with reasons why.
Also feels as a waste of effort when so many are making their own version of an extension instead of bundling the effort making one really nice one with all required features.

Thoughts/Opinions?

Edited Monday at 09:46 PM by Jos

[IronFine]

I started using VSCode with Damien/Loganch extension 3 years ago. It feels like, I picked up the pace when programming, but that is more due VSCodes capabilites (fast search etc.)

For some reasons I sometimes still end up using Scite, most likey because I have been using it for about 15+ years.

A community driven extension would be really nice.

[argumentum]

Love SciTE. Don't understand VSCode. Tried for over an hour and, love SciTE4AutoIt3.

Now, VSCode is an editor and I should be able to get used to it. If an extension removes the need for having to maintain all these utilities + a full fledged editor, I guess is a solution for that. And people abroad are very familiar with it ( VSCode ) so, it would not be a bad idea.

Did I say that I love SciTE4AutoIt3 ?..., yes I did. And like @IronFine, is all I used for AutoIt since 2005. VSCode would be an interesting move for me.

[SOLVE-SMART]

12 hours ago, Jos said:

I see that there are multiple efforts to create/maintain an AutoIt3 Visual Studio Code extension

In my point of view there are only two relevant VSCode extensions which exists and are actively maintained.

By @LoganCH :

VSCode marketplace:     https://marketplace.visualstudio.com/items?itemName=Damien.autoit
GitHub:                 https://github.com/loganch/AutoIt-VSCode
Unique Identifier:      Damien.autoit
Released on:            2015-11-25
Last updated:           2025-01-29
Extension creator:      Damien
Current maintainer:     @LoganCH
Subjective assessment:  the mature one, widely spreaded

By @genius257 :

VSCode marketplace:     https://marketplace.visualstudio.com/items?itemName=genius257.autoit
GitHub:                 https://github.com/genius257/vscode-autoit
Unique Identifier:      genius257.autoit
Released on:            2021-10-24
Last updated:           2024-12-17
Extension creator:      genius257
Current maintainer:     @genius257
Subjective assessment:  the new one, high potential but still with a lack of features

 

12 hours ago, Jos said:

I would like to open a discussion to see how that can be streamlined/merged/done more effectively so we can come up with the one that's preferred

Great - community driven would be really nice 👌 .

12 hours ago, Jos said:

I have been toying with the idea to stop the development of all the LUA extra's used by SciTE and start using VSCode

Understandable.

12 hours ago, Jos said:

I really like what I see and think this is a good way forward.

Totally agreed. I personaly use VSCode since many years - last but not least because 💡 I don't have to leave the editor for various tasks. Work on JavaScript, Json, AutoIt, golang whatever in just one editor (IDE). Really useful and powerful.

12 hours ago, Jos said:

Also feels as a waste of effort when so many are making their own version of an extension instead of bundling the effort making one really nice one with all required features.

I don't believe that several persons "fork" the given VSCode extensions and build a subversion for their own. I think we really should just focus and the two (better on one of them) I described above.

⚠ I also would like to here the maintainers and how they think of it. Also what will be the future plan for the extensions.

In my understanding, what you suggest @Jos, is how the GitHub projects/repositories (VSCode extensions) should be used or how they already are used. But in a wider range of contributers 💚 .

5 hours ago, argumentum said:

VSCode would be an interesting move for me.

I am quite sure, you @argumentum would not regret to take this step 😀 .

 

Best regards
Sven

Edited yesterday at 08:00 AM by SOLVE-SMART

[IronFine]

6 hours ago, argumentum said:

Love SciTE. Don't understand VSCode. Tried for over an hour and, love SciTE4AutoIt3.

That sounds a lot like my first steps with VSCode. I had to "force" myself to use it and nowadays I love AutoIt @ VSCode.

The single biggest improvement for my daily work is the problems tab in VSCode. Getting directly feedback where I have an syntax error or whatnot is so amazing.

 

1 hour ago, SOLVE-SMART said:

In my understanding, what you suggest @Jos, is how the GitHub projects/repositories (VSCode extensions) should be used or how they already are used. But in a wider range of contributers 💚 .

Having someone like Jos supporting the VSCode extension would be a huge benefits. Judging by all the fantastic work he has done over the last decade with SCITe that could really help to improve the extenstion even further.

[Jos]

6 hours ago, argumentum said:

Love SciTE. Don't understand VSCode. Tried for over an hour and, love SciTE4AutoIt3.

... and that is fine. SciTE will remain, but somebody just needs to figure out how to maintain Lua scripts when added functionality is required.

Let's concentrate here on the VSCode discussion.  
 

Edited yesterday at 09:14 AM by Jos

[Jos]

3 hours ago, SOLVE-SMART said:

I don't believe that several persons "fork" the given VSCode extensions and build a subversion for their own.

Thanks for your detailed views! 
I wasn't referring to forks, just the fact that there are multiple published extensions for Autoi3.
I made my own fork for testing, as I wanted to add the direct execution of Tidy, Au3Check and Au3stripper into the extension without running AutoIt3Wrapper and using the same shortcuts as currently within SciTE4AutoIt3.
Really wondering why @genius257 decided to start his own version and what are the Pros & Cons of either version. 
In general, I do not have the desire to "take any lead" or "take over" any of these project, just like to support one of them with the utilities I developed over the years to support one of these projects.  When the outcome is that the 2 separate extensions remain, that is fine with me too, but I will only select one to use and possibly support with pull requests. 

So what are the differences between these 2 projects, and what makes the one better than the other? (Positive comments please and no pissing contest!  )

Edited yesterday at 10:03 AM by Jos

[argumentum]

Every time I hear LUA, I can't help to hear Ha Louie Louie ..., in my head 

I'll take a look at Damien.autoit and genius257.autoit to have a clue on how these extensions work when I get some time to look at it. ...and install VSCode to see what the fuss is all about. Am sure that if I get to understand how it gets configured, I'll be comfortable using it. ...also because I'd like a good html/css/js/php editor to use too. I guess am thinking out loud again.

I'll post again if/when I get a consensus of these extensions.

Edit: genius257 has "@azure dependencies" so that may be the reason for having 2 I think. ( I don't use azure nor have an account. ) Maybe that's the reason for @genius257 coding his own solution ?

Edited yesterday at 10:43 AM by argumentum
..digging in to it ( for a few minutes, I have to get back to work )

[genius257]

I did originally use the Damien.autoit extension in vscode myself, and found issues I wanted to fix via pull requests. But after looking at the usage of regular expression and the reliance on AutoIt executables (nothing wrong with that as such, I mean it works), I wanted to try a entirely different approach.

 

4 hours ago, Jos said:

Really wondering why @genius257 decided to start his own version and what are the Pros & Cons of either version.

I started implementing my own extension after I experienced inconsistent behavior from the Damien.autoit version. For example: sometimes the suggestions did not work as expected, with no error messages.

I was also working on a AutoIt parser in Pegjs grammer syntax (now Peggyjs) and saw it as the perfect opportunity for testing it's capabilities. My extension does not depend on any files from AutoIt installations, and therefore works in web (test here: https://vscode.dev/) and on on non windows environments, like Linux (I use Ubuntu from time to time).

The Damien.autoit extension uses regular expressions to parse the file (for completions and such), where I use my parser as mentioned before.

My extension also runs via LSP, Damien.autoit does not.

There are also small differences like incorrect syntax highlighting for nested comments on the Damien.autoit extension (this issue can be fixed by looking at my tmLanguage implementation). Try this between the two extensions as an example:

#cs
#cs
#cs
#ce
#ce
#ce
$a

 

To be clear I am not saying my extension is superior. My extension is currently slower at parsing scripts, the parser i am using/developing is in active development and incomplete (with code blocks are currently not implemented) and since I don't use AutoIt executables for error checking there is currenly little to no error checking, besides the syntax check (and recently error messages for include statements that fail to resolve). This also means that to run AutoIt scripts with my extension, a secondary extension is needed (https://marketplace.visualstudio.com/items?itemName=genius257.autoit3-debug)

My extension is also made to move towards what I want for the AutoIt development experience. This means support for a new, more standardized doc-block way of documenting function and variable declarations. The standard UDF documentation format is supported for backwards compatibility, but is currently not great, and will only ever be implemented by me to "good enough" standard.

 

3 hours ago, argumentum said:

genius257 has "@azure dependencies" so that may be the reason for having 2 I think. ( I don't use azure nor have an account. ) Maybe that's the reason for @genius257 coding his own solution ?

I am unsure what you mean by "azure" dependencies?

The only azure i am using that i know of, is for auto deploying to vscode extension marketplace and Open VSX Registry automatically, when a new release is created on GitHub, via GitHub actions?

Edited yesterday at 01:47 PM by genius257

[seadoggie01]

While I've been moving away from using AutoIt lately, I started using Visual Studio Extensions about a year ago. I started with Damien/LoganCH's extension because it was the only available option at the time (I think). That said, there were a few issues (I think mostly Code Folding issue #89 - that's still open) with it at the time that caused me to start using genius's extension as soon as it came out. It was slightly choppy at the start, but considering my reduced usage of AutoIt, it's been fairly smooth sailing. Lately, I can't find a single issue with it despite it being "less mature"  But I also use AutoIt for fairly simple things now like making a GUI wrapper for a command line program written in C#.

Perhaps the other thing to consider is that LoganCH's extension requires the full SciTE install to function, per the ReadMe

Obviously I'm biased; I don't want to change my extension

[ValentinM]

I’ve been using PhpStorm and VSCode for a few years now, and I couldn't get used to SciTE (although I use it occasionally because of its lightweight nature).

That’s why I managed to make things work with @genius257's extension, as Damien’s version was old (not updated since a long time when I tried it) and highlighting all our base code in red (since we’re using OOP and multiple files in my team). The extension fits my needs perfectly.

Additionally, I developed my own extension to open the AutoIt Help when I press a shortcut, with the function under the cursor automatically selected in the Help GUI. I also released an update today (what a coincidence !) to support UDF .chm files: AutoIt Tools (not a big work as a debugger, but I needed it).

EDIT : (add) -> I managed to use VSCode's tasks, preLaunchTasks and launch settings to automatically start Au3Check before compiling so I have no issues.

Edited yesterday at 02:11 PM by ValentinM
Added Error check elements

[argumentum]

56 minutes ago, genius257 said:

I am unsure what you mean by "azure" dependencies?

I'd say that am new to it but to be frank, am a step behind new
I saw in "package-lock.json" a bunch of "@azure" entries and the other repo. does not have those entries, hence my assumption.
Saw a bunch of arm(CPU) entries and imagined that "he is coding in a raspberryPi AutoIt via Azure Extensions, interesting" but is just my imagination as I see now.

Maybe I should write "Mr.Robot v2.0, the re-incarnation" given my dream like, tech-fy brain

[WildByDesign]

I think that this is a great idea. My productivity is much higher in VSCode. I have used the AutoIt extension from genius257 for about a year now.

When working with AutoIt code, I always have the Au3 files open in SciTE4AutoIt3 and VSCode at the same time and continuously switching back and forth.

For doing things such as large numbers of Search/Replace, VSCode is far superior here. Just the Search/Replace functionality alone is quite significant of a difference.

I would imagine that maintaining the old code from SciTE4AutoIt3 is also likely cumbersome.

This thread made my day.

[genius257]

56 minutes ago, argumentum said:

I'd say that am new to it but to be frank, am a step behind new

No worries I was just wondering if I'd accidentally added something

56 minutes ago, argumentum said:

I saw in "package-lock.json"

Never look at the lock file The lock file is the entire resolved dependency tree, whereas the normal package.json contains the list of dependencies directly related to the project the azure dependencies are used by "@vscode/vsce" (https://github.com/genius257/vscode-autoit/blob/master/package-lock.json#L1900) and the "@vscode/vsce" is listed as a dev-dependency (https://github.com/genius257/vscode-autoit/blob/master/package.json#L149)

Edited 23 hours ago by genius257

[SOLVE-SMART]

Many thanks to everyone, especially to @genius257 for your well written assessment and your explanation 👌 .

A few pros and cons were already mentioned which is great.
I really looking forward to @LoganCHs opinion and to his statements about his VSCode extension (origin by Damien, "damien.autoit").
I believe he is pretty busy and maybe cannot work on the extension much more. At least that's my impression over the last few months or maybe even the last two years. The GitHub "issue" area is relatively full and only a few of the requests were processed promptly. 💡 Important: This is really not meant to be a criticism, as I really enjoy working with VSCode with the extension, it's just an statement. Hence the question of how he sees the future in this regard or if he would like support with further development.

Best regards
Sven

Edited 23 hours ago by SOLVE-SMART

[BinaryBrother]

23 hours ago, Jos said:

So...  I like to hear how you all think about this and possibly your preferred VSCode autoIt3 extension with reasons why.
Also feels as a waste of effort when so many are making their own version of an extension instead of bundling the effort making one really nice one with all required features.

Thoughts/Opinions?

VSCode seems to be widely used. The predictive features of VSCode are incredibly handy and GitHub's Co-Pilot has access to AutoIt's documentation.

As far as wasting effort, maybe grouping with @genius257 and @LoganCH could accelerate the process of officiating an AutoIt extension.

I've been experimenting with the damien.autoit @LoganCH extension and am highly impressed. He's put some time and effort into it.

[Danp2]

I've been using VSCode as my primary coding tool for a while, so anything that can be done to improve integration with AutoIt is welcomed. FWIW, I have both of these extensions installed / enabled at the same time, and it's working ok for me.

[Jos]

1 hour ago, Danp2 said:

FWIW, I have both of these extensions installed / enabled at the same time, and it's working ok for me.

How does that exactly work in VSCode as I assume(d) only one can be active and perform the lexing/syntaxcolor and monitor the shortcuts to run/compile?

[Danp2]

@Jos Good question. I just quickly reviewed my settings, but I don't see where I disabled anything in either extension. I suggest that you try it yourself and see if you encounter any issues.

[SOLVE-SMART]

2 hours ago, Jos said:

How does that exactly work in VSCode as I assume(d) only one can be active and perform the lexing/syntaxcolor and monitor the shortcuts to run/compile?

That is not easily answered. I try as best as I read some MS docs in the past and this is how I understood the behavior:

You can have multiple VSCode extensions with almost the same purpose. How they work together depends on the extensions (which configuration files are embedded or used). The order of the extensions also matters. Suppose one extension is called "color-picker" and another "colour-picker" and both are almost identical, VSCode will then choose either the first match or the latest one or even decide on the naming.

It is rather rare that one extension completely influences the functionality of another. But this does not mean that there are not or can be problems, that's for sure. To analyze it properly, you would have to pay attention to few things that are recommended by Microsoft regarding creating a VSCode extension.

I believe two different approaches were used for the specific extensions and that therefore they can coexist without any problems. But at least one of them will not be able to provide all the functionality, because VSCode decides to give priority to only one of them.

Best regards
Sven

Edited 18 minutes ago by SOLVE-SMART