OutputDebug settings are ignored; output after last newline is lost

[Lexikos]

In my launch configuration, I have

            "useOutputDebug": {
                "useTrailingLinebreak": true,
                "category": "console"
            },

and have also tried inverting the settings, but there appears to be no effect whatsoever. Output from OutputDebug is always red. Trailing line breaks are never added automatically. This appears to be contrary to the wiki and autocomplete/info tips within launch.json.

A second issue is that any output after the last `n is not shown in the console at all. If I see messages merging together, I at least know to add `n; but if the message doesn't appear at all, it leads me to confusion or false assumptions.

I am using v1.11.0.

[zero-plusplus]

I checked in the following environments and could not confirm the issue.

• Debugger Adapter Version: 1.11.0
• AutoHotkey Version: 2.0.11 and 1.1.36.02 (Unicode)

The following source code confirmed this.

#Warn All, StdOut

OutputDebug("line1`nline2")

#Warn All, StdOut

OutputDebug % "line1`nline2"

[Lexikos]

The issue is with launching the debugger via vscode-autohotkey2-lsp. I did not realize I was doing that.

I had a keybinding setting to disable the F5 shortcut defined by that extension, but it had stopped working because the condition defined for the keybinding no longer matched. So I was expecting F5 to be running the debugger directly, when it was activating the corresponding function of the LSP, which then launches the debugger.

The LSP has a setting for "Default Debugger" which is set to zero-plusplus.vscode-autohotkey-debug, so I am confused that there are such differences in behaviour when the LSP launches the debugger.

[zero-plusplus]

Thanks for the report. Please let me know anytime if there are any conflict issues that need to be resolved on our side.

I will also hurry to complete v2.0.0 so that it can be addressed soon.

[Lexikos]

I opened up VS Code on another computer to try to prove that the LSP causes a difference in behaviour, and instead proved that it does not.

The LSP is designed to launch the debugger even if no launch configurations are present. I assume it creates its own launch configuration, using whichever AutoHotkey interpreter is selected in the status bar. It shows the following text in the debug console:

"C:\Program Files\Autohotkey\v2\AutoHotkey64.exe" /Debug=127.0.0.1:9002 /ErrorStdOut c:\Scripts\Test.ahk
Debugger Adapter Version: 1.11.0
Debug Configuration (launch): AutoHotkey2 Debug
AutoHotkey Version: 2.0.12
line 1
line 2
AutoHotkey closed for the following exit code: 0
Debugging stopped

It clearly isn't using the launch configuration I selected, as that has a different command line. Since it isn't using the launch configuration, it makes perfect sense that it would use the default console output settings.

So to compare, I removed "useTrailingLinebreak": true from my launch configuration, and the issue was present regardless of how I launch the debugger.

I found it relates to word wrap:

"debug.console.wordWrap": false

On my laptop, I have installed the latest VS Code and deleted everything from settings.json except for the above. The only extensions installed are the LSP and debugger.

In the output, line 2 appears if word wrap is enabled and disappears if word wrap is disabled. This happens in real-time as the settings are saved; it is not necessary to re-run the script.

I'm guessing that your extension adds a single message/element to the output pane for each stderr/stdout packet, as OutputDebug("`nline 2") exhibits the problem whereas OutputDebug("`n") followed by OutputDebug("line 2") works fine even without word wrap. So although this might be a VS Code bug, I'm sure you could work around it by having your extension split lines before sending them to the console.

[zero-plusplus]

Certainly "debug.console.wordWrap" seems to be the cause. Maybe related to vscode Issues#151768 (filter is:issue is:closed #151768) (It is not a direct link to prevent it being associated).

Your workaround of splitting messages into line breaks is a good idea. The concern is that vscode treats one message as a group, so splitting them would cause them to be treated as separate groups.

It may therefore be best that the vscode bug is fixed.

---

Since it is inconvenient to not be able to implement workarounds because of side-effects, how about implementing the following launch.json attribute that sets whether or not the workaround should be used, as follows?

  "workaround": {
    "#323": true
  }

[Lexikos]

The workaround idea sounds fine to me.

[zero-plusplus]

Thank you.

I think this mechanism allows us to implement the original mechanism of the debugger as simply as possible.