Extend runtime and runtimeArgs, and deprecate *_v1 and *_v2

[zero-plusplus]

Names like runtime_v1 and _v2 are not so clear. To make it clear that they are tied to an language ID, extend them as follows:

...
    runtime: {
        "ahk": "AutoHotkey.exe"
        "ah2": "v2/AutoHotkey.exe"
        "ahk2": "v2/AutoHotkey.exe"
    }
    runtimeArgs: {
        "ahk": [ "/ErrorStdOut=UTF-8" ]
        "ah2": [ "/ErrorStdOut" ]
        "ahk2": [ "/ErrorStdOut" ]
    }
...

The reason for making this change is not only to clarify the effect of the configuration, but also to prepare for the plans to accept ahkh, ahkh2 as a language ID for AutoHotkey_H.

I'm also considering a change that would also allow the runtime to be configured in settings.json, as shown below. This is an unpublished plan for vscode-autohotkey.

...
ahk.runtime: "C:\\Program Files\\AutoHotkey\\AutoHotkey.exe"
ahk2.runtime: "C:\\Program Files\\AutoHotkey\\v2\\AutoHotkey.exe"
ahkh.runtime: "C:\\Program Files\\AutoHotkey\\h\\AutoHotkey.exe"
ahkh2.runtime: "C:\\Program Files\\AutoHotkey\\h\\v2\\AutoHotkey.exe"
...

These changes make *_vX unnecessary.

[zero-plusplus]

I noticed that the description of *_vX in the README is not correct. It is written as if it is tied to each file extension, but in fact it is tied to the language ID.

[zero-plusplus]

I discard this draft.
In the future, runtime will be deprecated and replaced with the more general runtimeExecutable.

The runtimeExecutable only accepts absolute and relative paths.

If set it for each AutoHotkey version, you have to set it in setting.json. In that case, set it for each language ID, such as ahk.runtimeExecutable or ahk2.runtimeExecutable.

[SAbboushi]

I'm also considering a change that would also allow the runtime to be configured in settings.json, as shown below. This is an unpublished plan for vscode-autohotkey.

If set it for each AutoHotkey version, you have to set it in setting.json

I don't use setting.json, I use workspaces e.g. AHKv2.code-workspace, AHKv1.code-workspace, AHKv2.0-a116-6bb8f6c4.code-workspace...

Will I still be able to do this in vscode-autohotkey?

[zero-plusplus]

Incorrect: setting.json -> settings.json

You can change the settings for each workspace by creating a .vscode/settings.json for each workspace.

If this is still inconvenient, I will extend runtimeExecutable to accept objects keyed by language ID.

[SAbboushi]

Sorry - seems I missed your response.

You can change the settings for each workspace by creating a .vscode/settings.json for each workspace.

I believe the settings.json is USER settings, not WORKSPACE settings. And I believe that WORSPACE settings override USER settings.

If this is still inconvenient, I will extend runtimeExecutable to accept objects keyed by language ID.

Sorry - I don't understand

[zero-plusplus]

It seems that I did not know enough about workspace.

The workspace settings are recorded in .code-workspace instead of settings.json. There is no difference between them, so you should be able to configure runtimeExecutable without any problems.

---

If this is still inconvenient, I will extend runtimeExecutable to accept objects keyed by language ID.

Sorry - I don't understand

This statement means that if you can't set it in workspace, you can set it in launch.json as before by extending runtimeExecutable as follows.

runtimeExecutable: {
    "ahk": "AutoHotkey.exe"
    "ah2": "v2AutoHotkey.exe"
    "ahk2": "v2AutoHotkey.exe"
}

However, this will not be implemented as it can be configured without any problem as explained above.

[SAbboushi]

The workspace settings are recorded in .code-workspace instead of settings.json. There is no difference between them, so you should be able to configure runtimeExecutable without any problems.

Excellent

This statement means that if you can't set it in workspace, you can set it in launch.json as before by extending runtimeExecutable

I'm also not using launch.json: my launch configurations are in the .code-workspace files