[Feature Request] Support Environment Variables and PATH Auto-Discovery for Interpreter Path

[Hzbeta]

The "Interpreter Path" setting in the AutoHotkey v2 Language Support extension requires an absolute path. It does not support environment variables or auto-discovery from the system PATH. When AutoHotkey is installed via scoop, a package manager for Windows, using scoop install autohotkey, autohotkey.exe is automatically set in the system PATH. It is recommended that setting this attribute to simply autohotkey.exe should allow the extension to locate the executable automatically.

---

AutoHotkey v2 Language Support 扩展中的 "Interpreter Path" 属性必须为绝对路径，并且不支持环境变量或自动从系统 PATH 中发现路径。如果使用 scoop（Windows 包管理器）安装 AutoHotkey (scoop install autohotkey)，autohotkey.exe 会自动加入系统 PATH 中。希望可以支持将此属性简单的设置为 autohotkey.exe，不必指定具体路径，扩展也能够根据环境变量自动找到可执行文件的绝对位置。

[thqby]

Currently, this feature is supported.

[Hzbeta]

I conducted more detailed testing, and I found that Scoop adds autohotkey.exe to the PATH in a rather unique way. Instead of adding the directory containing AutoHotkeyUX.exe to the PATH, it creates a shim program, which will then launch the installed AutoHotkeyUX.exe. Therefore, in this case, setting the "Interpreter Path" directly to autohotkey.exe leads to an error where the extension keeps displaying "Failed to get script built-in variables, such as A_MyDocuments." I suspect this is because the extension is reading the contents of autohotkey.exe, but it is merely a shim program and not the actual AutoHotkeyUX.exe. Given this situation, I think that trying to make the extension compatible with Scoop’s unique way of setting the PATH may not be a good idea.             

An alternative, more universal approach to support Scoop is by using environment variables. I tried using environment variables in the "Interpreter Path" property, such as %USERPROFILE% or ${env:USERPROFILE}, but they all failed. I wonder if this extension supports environment variable expansion? If it's not currently supported, is there a plan to support it in the future? This extension is fantastic, and I really appreciate your efforts!  

[thqby]

I started ahk by specifying the ahk interpreter path as shim.exe, and still got the ahk script variable, but it showed an unknown version in the status bar.

[Hzbeta]

My environment versions:

• AHK: Latest version 2.0.18
• Scoop: Latest version 0.5.2
• VSCode: Latest version 1.95.3
• AutoHotkey v2 Language Support extension: Latest version 2.5.5
• System: Windows 11 24H2 26100.2448

Reproduction steps:

1. Uninstall any existing installation of AutoHotkey and make sure its path does not appear in the environment variables.

2. Install AHK using scoop install autohotkey.

3. Open VSCode and install only the "AutoHotkey v2 Language Support" extension.

4. Create a new AHK file with the following content and switch to its tab:

   #Requires AutoHotkey v2.0
   
   MsgBox("Test")

5. Set the extension property "AutoHotkey2.InterpreterPath" to "autohotkey.exe". At this point, the extension will display the following error message: "Failed to get script built-in variables, such as A_MyDocuments." You can manually close the message.

6. Use the shortcut key to open the VSCode command panel, select "Developer: Reload Window", and wait for VSCode to reload. After reloading, the extension will still display the same error: "Failed to get script built-in variables, such as A_MyDocuments." In other words, the error appears every time you open VSCode.

Since there are no error logs in the output, I recorded a GIF to visually demonstrate this issue:

[thqby]

This is a problem with the shim program. It exits immediately after starting ahk. The extension executes the ahk script to obtain script variables. When the extension discovers that the started process has exited, it starts processing the returned information, and at this time, ahk has not yet started working.

In addition, running the script cannot get the correct exit code.

[Hzbeta]

Thank you for the clarification. Just to confirm, does the extension currently support environment variable expansion for the "Interpreter Path" (e.g., %USERPROFILE% or ${env:USERPROFILE})? If not, is there any plan to add this feature in future updates?

Thanks again for your efforts on this excellent extension!

[thqby]

I will add support for environment variables. e.g.,%USERPROFILE%