Bug: mapped keys seen as unmapped in WinCompose compose sequences

[nuanjanP]

Requirements

• [X] I've searched issues to see if this has not been reported before.

Describe the bug

Hi.

While I was trying to use kanata with WinCompose (on Windows 10), I found that keys mapped in kanata (via deflayer) are seen by WinCompose as their original pre-mapped versions (as in defsrc), causing wrong compose sequences.

Relevant kanata config

(minimal kanata config for remapping c to e)

(defcfg
  process-unmapped-keys yes
)

(defsrc
  c
)

(deflayer default
  e
)

To Reproduce

1. Map c in defsrc to e in the first deflayer. (You can use the minimal kanata config given).
2. Set WinCompose to allow injected keys
   1. Right click at WinCompose icon in systray > Options... > Tweaks tab > Advanced (lowest block)
   2. Check "Allow Injected Keys"
3. Type Composecc on the physical keyboard (where Compose is the key registered with WinCompose, for example, R-Alt).
4. See the resulting composed character.

Expected behavior

• expected result: ə (from the sequence Compose e e, as c key is mapped to e in deflayer)
• real result: č (from the sequence Compose c c)

Kanata version

kanata 1.4.0 windows (LLHook)

Debug logs

No response

Operating system

Windows 10

Additional context

No response

[jtroo]

Hmm maybe the code change here is needed? https://github.com/jtroo/kanata/issues/567

Could give it a try to see if that works. Otherwise maybe wincompose is reading via other mechanisms that the llhook/sendinput version of Kanata can't work with, maybe RawInput? I haven't looked too closely into if RawInput reads inputs before llhook.

[ShrykeWindgrace]

@nuanjanP Out of curiosity, what's your use case that requires running both kanata and wincompose at the same time?

[nuanjanP]

@nuanjanP Out of curiosity, what's your use case that requires running both kanata and wincompose at the same time?

@ShrykeWindgrace Sorry for the late reply. At the time I was trying out different mechanical keyboards, and because different keyboards define the function key(s) differently, it's a bit annoying, for example in my case, to remember which key combinations are used for volume adjustment for a particular keyboard. Now since function keys are hardwired, I came up with the idea of using kanata to define global key combinations with software instead, independent of the keyboard used.

On the other hand, I was already using WinCompose on a daily basis (for Duolingo for example). Personally I prefer compose sequences, compared to creating new keyboard layouts to accommodate for additional characters. So it's natural for me to be looking out for potential conflicts between the two. And it happened to be that while I'm learning how to write config files for kanata, I tried out the minimal use case, "swapping just two keys", and that's when I stumbled upon this issue.

In practice in my own case, there are ways to avoid this issue while accomplishing my goals, but it seems to me one worth noting, so I thought it wouldn't be too bad making a little report here :)