Report on the creation of extensions to support AutoHotkey development #90
Replies: 4 comments 11 replies
-
Thanks for the update. Looking forward to it! |
Beta Was this translation helpful? Give feedback.
-
I think this is good news! This looks like a tremendous amount of work - I wish that you will be rewarded and that lots of AHK users will adopt your new extension. Can you share more details about your extension's Built-in API and User-defined API? What is the purpose? Is this vscode-specific? |
Beta Was this translation helpful? Give feedback.
-
hi, I just discovered your extension this parser is not following any standards, I was too lazy to see how javascript parser worked I have not done msg
(
box
) hello world I think this REQUIRES preprocessing can you tell me what features you need in a parser ? I just learned about incremental parsing, this should be fast, if it is possible to do so on autohotkey I'll look into tree-sitter |
Beta Was this translation helpful? Give feedback.
-
Hi! I am also wirting a autohotkey supporting extension Autohotkey Simple Support. And ,you may be seen before, a debugger extension Autohotkey debug. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I use a DeepL translator.
2021/02/09
Currently I am developing another extension that supports all AutoHotkey versions (including H).
I have put the addition of features to this extension on hold in order to prioritize the development of that extension.
I was planning to release the first version of new extension in December last year, but I had to abandon it because the amount of work was much larger than expected.
Even though it is still in the development stage, there are more than 3,000 lines of syntax highlighting definitions (10 times more than the existing ones), more than 5,000 lines of API definitions. Eventually there will be more than 10,000 lines. These are the reasons for the significant delay in development.
I hope to release it by June if possible, but it may be postponed again.
However, I will definitely finish it, so I would appreciate it if you could wait a little longer.
As soon as that is completed, I'll implement the new features of this extension.
2021/04/13
I've been trying to detect symbols (classes, functions, etc.) for the past few days. As a result I realized that it is difficult to solve this without using a parser.
It takes a lot of time and knowledge to create a parser. To alleviate this, I considered using a parser generator, but gave up when I realized that it could not parse incomplete code (e.g., code when the user is typing).
So I decided to create a parser from scratch.
The reason for this decision was that there were other good extensions available, so I expected that releasing it early with few features would not increase the number of installations.
Increasing the number of installs (i.e. users) is important because feedback is necessary for development.
Once the parser is complete, I can implement many very attractive features, but as explained above, it will take a great deal of time and the release date will be far off.
Initially, I was planning to take about a year to complete the project, but my current estimate is that it may take 3 to 6 months. In other words, I aim to release it by the end of this year.
2021/07/27
I decided to replace the parser with a parser generator called tree-sitter.
tree-sitter is a parser generator used by Atom and other editors.
Because it is designed to be used in editors, it has features such as incremental parsing and error recovery when an unknown token appears.
The definition file can also be written in JavaScript, with support for relatively easy parsing of expressions, which can be complicated.
It has syntax highlighting capabilities, which, if supported by VSCode in the future, will eliminate the double management of syntax highlighting and parser definitions.
As the next generation parser, I am very hopeful that it will become a future standard and decided that taking the time to learn it would be the best way to proceed with this project.
2022/03/02
It's been a while since I've updated, but I haven't missed a work session.
I have not been able to work on the AutoHotkey parser because I have been busy updating this extension, but I have been working on it since 12/24 when I updated 1.10.0.
The work has been very difficult due to the difficulty of handling tree-sitter and the quirky syntax of AutoHotkey.
Currently, I am working on reorganizing the code because it was very unstable, although it is about 50% complete.
I hope to have it done by April, but there will easily be delays, as it can take up to a week to resolve a single issue.
2022-03-11
The parsing rate of my own library (10k lines) for AutoHotkey v1 is now 100%.
It is not yet complete, as it needs to implement some syntax, such as hotkey label statements that are not used in the library, but it is very close to completion.
After completion, I plan to implement syntax highlighting and intellisense using the parser.
After that, I will create a v2 parser.
2022-04-09
Added missing syntax such as hotkey labels.
In addition, a non-error but mis-parsed section has been corrected, and tests and parsing samples have been added.
After four months of work, the parser work can finally be completed.
My plans for the future are as follows
There is still more work to be done, but this is a multi-year plan, so please be patient.
2022-09-30
I am currently suspending development of this extension due to a problem that cannot be resolved.
Therefore, I have spent the last 5 months or so creating a previously planned AutoHotkey library to easily define complex hotkeys.
This is a project that I had planned for several years and had been put on the back burner by the creation of vscode extensions.
This is unfortunate news for those of you who were hoping for an extension, but since I needed a large sample library to create syntax highlighting and parsers, I took this opportunity to create one since development had stopped.
The library is almost complete, with only proofreading of the documentation and final testing remaining.
I plan to release it within the next month and get back to updating vscode-autohotkey-debug, but my plans tend to lag behind, so don't hold your breath.
2023-07-23
Development is still ongoing, and with the parser nearly complete, the type system can now be implemented.
This type system takes into account Include statements. That is, if you include a file with class B in a block of class A, the type system will understand the structure
A.B
.However, in order for the completion process to work correctly with a file of class B, the file with class A must be configured as root.
Thanks to treesitter's incremental analysis, the analysis speed is 30 ms for 3000 lines. (Only the first analysis takes about 5 times longer.)
If the number of lines is 8000, it will take a little longer, about 100 ms, but this can be solved by splitting the file.
The split file will not be reanalyzed unless it is modified. Therefore, including large libraries will not slow down the parsing speed of your scripts.
Since it takes an enormous amount of time to complete this type system, I will try to speed up the release of the extension by setting as small a goal as possible.
So far I have been able to implement automatic type determination for expressions and functions and type determination by jsdoc-like some annotations, which is quite useful.
If there are any features you would like to see incorporated, please let us know here.
I will report back here if anything else comes up.
Beta Was this translation helpful? Give feedback.
All reactions