BUG: repeat declaration of key in defsrc

[Fred-Vatin]

VS Code version	OS	Extension version
1.84.2	Win 10 x64 pro (french) 21H2	v0.3.0

Steps to reproduce

Try this config

(defcfg
    process-unmapped-keys yes
    log-layer-changes yes
)

(deflocalkeys-win
    lock 8
)

(defsrc
    lock
        7
)

(deflayer base
    _
        _
)

Results

It runs with no error in kanata but triggers the error in extension.

[{
    "resource": "/E:/OneDrive/Téléchargements/test.kbd",
    "owner": "Kanata Configuration Language",
    "severity": 8,
    "message": "Unknown key in defsrc: \"lock\"",
    "source": "kanata-parser",
    "startLineNumber": 11,
    "startColumn": 2,
    "endLineNumber": 11,
    "endColumn": 6
}]

I suspect the OSCode (base 10) is confused with scancode. In lock 8, 8 is the OSCode (base 10). The scancode for key 7 is 08.

With the key tester, 8 is for backspace and 55 is for key_7. It confirms there is no conflicts between the keys.

[rszyma]

Thanks for the bug report.

This bug is windows-only. It happens because kanata parser is compiled for wasm and if you look over kanata parser codebase you'll see that whenever a code is conditionally compiled based on target OS, wasm implementation would be missing. So either linux or windows implementation had to be choosen for wasm target. Arbitrarily, linux was choosen.

You can see an example of that here (target_os = "unknown" is for wasm): https://github.com/jtroo/kanata/blob/be561b23fa2e99ce7a8c79205a87669aca1e3d65/parser/src/keys/mod.rs#L7-L17

In order to fix this bug, a patch for kanata parser would be required, to allow selection of os-specific implementation (linux, win or wintercept) at runtime, instead of compile-time.

[rszyma]

Fixed in v0.4.0