Bug: key repeat for output chords using arrow keys does not work

[wis]

Is your feature request related to a problem? Please describe.

For keys bound to character keys, if you hold down the key, it repeats, e.g. if I hold e, it repeats like this eeeeeeeeeeeeeeee, this is also the case for any simple key-to-key mapping e.g. arrow keys.

This feature is needed to enable the repeat of motions like e.g. the visual selection of next character/line for the visual mode of the vim emulation layer I mentioned in an issue I opened previously (#648)

Here's the configuration for the visual mode layer:

(deflayer vim_mode_v_layer
  XX  XX    XX    XX    XX    XX    XX    XX    XX    XX    XX    XX    XX    XX   XX
  XX  XX    XX    @vim-m-vfwd-wrd    XX    XX    @vim-m-vbck-wrd    XX    XX    XX    C-c    XX    XX
  XX XX    XX    XX    XX    XX    @vim-v-g    XX    S-lft    S-down    S-up    S-rght    XX
  XX XX    XX    XX    XX    XX    XX    XX    XX    XX    XX    XX
  XX XX XX           XX      @tap:exitMode,hold:Esc XX XX
)

With this configuration, if you hold down j (bound to Shift+↓), only one line is selected and it does not keep on selecting down lines for as long as you hold the key, because repeat does not work for keys bound to modifier combos (aka shortcuts).

Describe the solution you'd like.

A way to enable repeat for keys bound to shortcuts, I don't know how the configuration syntax for this should look.

Describe alternatives you've considered.

I looked at all the available actions in config.adoc, but I couldn't find a way to configure this. the closest thing I found to the behavior I describe is (macro-repeat-release-cancel S-down 100), but this does not behave like key repeat, you can overshoot if you hold for too long, and the first press of the action does not take more than the later/repeat presses, all the presses (including the first) are pressed at the same frequency/rate.

Additional context

No response

[jtroo]

This seems like a bug rather than a feature request, this use case is intended to work today.

If you could, can you prepare a minimal and complete configuration that reproduces the issue, with logs using the --debug flag from doing the testing?

[wis]

Yes, of course. Here's the minimal config and the logs:
kanata.kbd:

(defsrc
  grv  1    2    3    4    5    6    7    8    9    0    -    =    \   bspc
  tab  ;    q    w    f    p    b    '    l    u    y    j    ]
  caps /    a    r    s    t    g    k    n    e    i    o    ret
  lsft z    x    c    v    d    [    h    m    ,    .    rsft
  lctl lmet lalt           spc            esc comp rctl
)
#|(defsrc
  grv  1    2    3    4    5    6    7    8    9    0    -    =    \   bspc
  tab  q    w    e    r    t    y    u    i    o    p    [    ]
  caps a    s    d    f    g    h    j    k    l    ;    '    ret
  lsft z    x    c    v    b    n    m    ,    .    /    rsft
  lctl lmet lalt           spc            esc comp rctl
)|#

(deflayer blank-layer
  XX  XX    XX    XX    XX    XX    XX    XX    XX    XX    XX    XX    XX    XX   XX
  XX  XX    XX    XX    XX    XX    XX    XX    XX    XX    XX    XX    XX
  XX XX    XX    XX    XX    XX    XX    XX    S-lft    S-down    S-up    S-rght    XX
  XX XX    XX    XX    XX    XX    XX    XX    XX    XX    XX    XX
  XX XX XX           XX     XX XX XX
)

I tried with a more minimal config: (defsrc 1 2 3 4 ) (deflayer start S-lft S-down S-up S-rght)
but shift did not work/press-down if it was not defined in defsrc, the way it's defined in the config above. (is that a bug?)

log: kanata3.log

In this reproduction of the bug, first, I tapped E for down, then held/pressed it down, then did the same for I (up), then N (left), then O (right).

Perhaps it's worth mentioning that, first, I remapped my keyboard layout using the "Windows registry method", and second, I use an unusual/unconventional keyboard layout, it's a variation of a variation of Colemak, it's a variation of Colemak-DH, which is a variation of the Colemak keyboard layout.

I should also mention that I do not use the Interception driver, and that kanata -V outputs kanata 1.5.0-prerelease-3 and that I use a binary of Kanata I compiled myself with the MAX_LAYERS constant changed to 200, with my local repo's last commit being 9a63529, committed 2 weeks ago, on the 2nd of December.

[jtroo]

Looks like the issue is related to a specific Windows-LLHOOK behaviour where the shift key is injected by Windows when pressing arrow keys with a certain numlock state. The key repeat issue started happening with this commit:

4da1456584 feat!: clear non-oneshot output chord on next action (#552)

It's hard to say off the top of my head what the best fix for this would be, so I'll defer on it for now. But here are some workarounds:

• toggle numlock - I was too lazy to check whether it should be on or off, but one of the settings reproduces the issue and the other does not
• use Interception (see caveats related to the interception driver)

[jtroo]

I think this is fixed by winiov2

[wis]

Yes, thanks, I just tested it by compiling with --features win_sendinput_send_scancodes,win_llhook_read_scancodes to use winiov2 and it seems to fix it. eventually at some point these feature flags will be removed and the changes be incorporated into the normal llhook build?