Planning the 2.0.0

[zero-plusplus]

Currently, I am rewriting the source code from scratch to improve future extensibility and maintainability.

The work can be viewed on the v2.0.0-develop branch.

---

I realized that marking something once doesn't make sense because I may end up reworking it later for refactoring or fixing it. Therefore, I'm going to treat it as a list of things I need to do, not as a progress indicator.

Existing features

• Debug configurations
  • Verification / Normalisation
  • Support for new attributes
• Meta Variable
  • Responding to changes in specifications
• Data inspection
  • Context menu
• Call stack
• Watch expression
  • Update evaluation process
• Loaded scripts
• Conditional breakpoint
  • Update evaluation process
• Hit conditional breakpoint
• Log point
• Debug console
• IntelliSense in debugging
• Perftips
• Breakpoint directive
• Output directive
• ClearConsole directive

---

Add

• Add Function breakpoint #31
• Add {callstack.trace} #224
• Support for automatic selection of runtime #241
• Support exception breakpoints #257
• Add runToEndOfFunction vscode command #264
• Add setBreakpoints attribute in launch.json #266
• Add command variables #271
• Implement "Set debugging watch values" #272
• Support autocomplete in the debugging console and conditional breakpoint #286

Change

• Output all error messages to the debug console #60
• Enhanced conditional breakpoints #116
• Support for multi-line output with @Debug-Output #225
• Change breakpoint directive to break regardless of output #238
• Pre-release support and raising the supported vscode version to 1.63 #239
• If program is UTF-8 with BOM, add /CP65001 to runtimeArgs. #240
• Implement format specifiers at log points, etc. #244
• Support the expression in watch expression #261
• Support the expression evaluate in debug console #269
• Change the syntax of debug directive #275
• Japanese support for documents #282
• Change the labelling process when outputting objects to the log #288
• Change to allow child element to be retrieved even in bracketed notation #293
• Show the name attribute on debug configuration errors #306
• Change specification when relative paths are specified in the runtime attribute #307
• Rename some metavariables to more appropriate names  #309
• Category enhancements and disruptive changes #312
• Support Debug Visualizer #320
• Output object directly, without label #322

Fix

• Attach script fail #207
• Cannot detect some errors #212
• The list of running AutoHotkey processes displayed before attaching does not display correctly when it contains multibyte strings #215
• ;@Debug-Output grouping not working #220
• Raw message displayed on Critical Error #229
• @Debug-Output, object with dynamic keys not working #232
• Debugger features do not work with UNC paths #234
• Debugging gets stuck if the last line of the included script is a debug directive #236
• Hover information is not displayed correctly. #245
• When a string containing # is displayed in View Value and View as Text in the Variable View context menu, the subsequent string is not displayed #254
• Objects with child elements in index notation such as ["a & -"] may get stuck when retrieving child elements #255
• [v2] If double/single quotes are used in #Include directive, they do not appear in Loaded Scripts #256
• I can't attach debug to the running script (latest ahk v2). #262
• If an empty string is passed as the value for writing a variable, the string "Not initialized" is written. #273
• No warning when wrong child attributes are specified in launch.json #283
• The extends attribute in launch.json does not work in the multi-root workspace and throws an error #285
• If debugging is terminated by an error, debugging may not start until vscode is restarted #291
• Loaded Scripts may not be displayed #292
• Debug output incorrectly merged #301
• Questions about prototype information presentation #302
• useAutoJumpToError: hyperlink excludes line # #311
• Recursion error #321

---

Remove

• Add pseudo-variable ${ahk:suppressErrorDialog} #213
• Add pseudo-variable ${ahk.pinnedFile}. #248
• Complete remove "ahk" in deprecated type attribute value #263

---

Task

• Functions for conditional breakpoints, etc. #289
• Creating automatic tests for debugging clients #294
• Add a note to the wiki on how to debug scripts that use administrative privileges
• Update Evaluator to match metavariable specification changes. e.g. GetMetVar("variableCategories").Global
• If an error occurs in a library available in the expression, it raises an error rather than returning an empty character and displays this information in the console

Confirmation

• Questions about prototype information presentation #302
• "Error: Gui has no window" when debug adapter evaluates a destroyed Gui object #317

---

Backlog

• Add decorations to the tabs of program file #253
• Ideas about DependentBreakpoint #313
• Display breakpoint information on the code #314

---

Remaining work to release

• Test
• Check security patches

[mark-wiemer]

Hi, I worked with Stef Levesque to discontinue slevesque.vscode-autohotkey, see stef-levesque/vscode-autohotkey#32. My extension, AutoHotkey Plus Plus, shouldn't cause conflicts with the debugger as it's hardcoded to use your extension if it exists.

My goal is to have one extension (or extension pack) that AHK coders can use to write both AHK v1 and AHK v2 scripts with full language support--good IntelliSense, syntax highlighting, formatting, and debug support.

I'm hoping we can work together to discover the best way to support AHK coders moving forward, I'd hate for us to both do the same thing. Please let me know if there are any conflicts between AutoHotkey Plus Plus and your extension, and I'll work to remove them.

[zero-plusplus]

Thanks for the explanation.

You and I have different goals. My initial goal was to assist in the creation of my own library.
Therefore, I want the extension to fulfill 100% of my requirements. This can only be achieved by my own creation.

And unfortunately we will not be able to cooperate. I would also not collaborate, because the multi-person development would be a barrier to incorporating my own ideas.

We will create similar extensions, but they will each have their own good and bad points.
They may lead to better subsequent extensions.

That would be preferable to me.

---

I will report back to you when there is a possible conflict😄