Add /CP65001 to the default value of runtimeArgs

[zero-plusplus]

Add an argument to make UTF-8 the default encoding used to load scripts.

This will allow source code containing multibyte strings to be executed correctly.

[Lexikos]

This will allow source code containing UTF-8 to be executed correctly.

It will cause source code which contains other multibyte strings to be executed incorrectly.

I would generally recommend using UTF-8 for scripts, but that isn't the default for AutoHotkey v1. Adding /CP65001 by default might only be appropriate for users who have /CP65001 registered in HKCR\AutoHotkeyScript\shell\Open\Command.

I suppose if VSCode already interprets the file as UTF-8 anyway (I haven't checked but wouldn't be surprised), there is a reason to do it even if the open shell verb does not.

AutoHotkey v2 defaults to UTF-8 without /CP.

If both v1 and v2 are installed, the UTF8 value in HKCU\Software\AutoHotkey\Launcher\v1 may be set to 1 to cause the launcher to add /CP65001 when executing v1 scripts.

[zero-plusplus]

The reason I decided to make UTF-8 the default is that when I was a beginner who did not yet know character encoding, I had a very difficult time finding out why source code containing multibyte strings could not be invoked.

However, I decided to revert this change because it would cause similar difficulties for users who do not use UTF-8.

Debugging via Launcher does not seem to be able to retrieve streams such as stdout, so any changes made to Launcher would not be reflected in the extension here.

I've come up with the idea of enabling this setting only when the runtime encoding is UTF-8 as one solution, but what about this?

There are two issues with this: the encoding may or may not be read correctly, and this behavior is set automatically and cannot be changed by the user.

But, I don't think the second is much of a issue, though, since I don't think anyone doesn't want to use the UTF-8 setting while using UTF-8 for encoding.

[Lexikos]

Debugging via Launcher does not seem to be able to retrieve streams such as stdout

I'm not sure what you mean exactly, but I do not think this is a limitation of the launcher or AutoHotkey. Stdout output from the actual script is echoed by the launcher regardless of whether there is a debugger connection. I have confirmed this by using a command line like v2\AutoHotkey.exe UX\launcher.ahk /Debug Script.ahk | more and dbgp_console.ahk.

I assume you would be redirecting stdout of the launcher process, while receiving a TCP connection from the actual script process (not the launcher process). Maybe this causes an issue for your extension.

For tools that are aware of the launcher, I considered that it might be better for the launcher to provide command-line usage that passes back the identified version, the path to the interpreter, and any proposed command line switches (such as /cp65001) for launching the script. In other words, you call the launcher to determine how to launch the script, then you launch the script directly. (Or you can call the launcher just to determine which version of AutoHotkey the script is for.)

[zero-plusplus]

Stdout output from the actual script is echoed by the launcher regardless of whether there is a debugger connection.

I did not know this. I will try it when I have time.

[Lexikos]

I presume your extension reads the actual stdout stream. If it was redirecting stdout with stdout -c 2, that would also work because it comes through the DBGp connection, which is made between the actual script and the DBGp client (extension). That also works if you attach to a running script.

[zero-plusplus]

Thanks for the info.
Newly opened issue on debugging with launcher.

---

I'm closing this because I opened an alternative issue.