tap-hold-press on shift keys means shift+mouse click/wheel stops working

[riotrah]

Hi!

I know I'm probably configuring this incorrectly, as I've had my stable kanata config running for over a year now without changes (a testament to this projects fidelity and quality, btw) so I'm a lil out of the loop. Apologies if I missed an existing issue or discussion that answers this for me.

I wanted to add the following new feature to my config:

• Left shift tap -> insert ( character, hold -> L shift as usual
• Equivalent for Right shift, with ).

I did this like so:

(defalias

  ...

  ;; tap: open paren, hold: lshift
  lsftp (tap-hold-press 200 5000 S-9 lsft)
  ;; tap: close paren, hold: rshift
  rsftp (tap-hold-press 200 5000 S-0 rsft)

  ...	

)

This worked great for all pure keyboard usage; shifts still worked flawlessly as modifiers for keypresses, including with other modifier keys no matter the order. It even kept working with my capslock-hyper-key setup, where capslock + shift + h correctly outputted shift + left.

However, mouse-related actions like shift+mousewheel to scroll horizontally, and shift+left click to bulk select things in windows explorer or other apps etc, no longer worked.

That is, shift + mouse click/wheel => mouse click/wheel. It dropped the shift completely.

Interestingly, if I add an extra modifier, then together the modifiers do work:

shift + control + mouse click/wheel => shift + control + mouse click/wheel

However, the order in which I hold the modifiers matters - I have to press shift first:

ctrl + shift + mouse click/wheel => ctrl + mouse click/wheel. Ie, drops the shift again, but:

shift + control + mouse click/wheel => shift + control + mouse click/wheel. Works correctly.

---

What should I do? Anything else from my config I should share?
I'm currently using the llhook, as the interception driver (still) has the headache that it won't work if you use wireless kb/m with a laptop that sleeps often.

[jtroo]

Noticing that your timeout is set to 5000, my guess of what the problem is: the lsft | rsft don't actually activate in a reasonable amount of time. It takes 5 seconds for the "hold" action to activate if there haven't been other events to trigger the -press early activation.

This can be worked around in interception and Linux because the mouse can be intercepted and its events can be used to trigger the -press early activation, while keeping mouse functionality mostly the same. But the llhook mechanism doesn't support mouse events yet.

Another workaround you can do is to avoid tap-hold and use multi. Since, for most scenarios, lsft on its own has no output, you can simply always output the lsft and conditionally output the ( and ). Sample.

[musjj]

But the llhook mechanism doesn't support mouse events yet.

Has anything changed about this on Linux?

[riotrah]

Thanks for your promptness as always.

And wow, kanata's got quite a bit more features than I last remember it. This really is one of the most impressive projects I've seen by a (presumably) solo author. I need to do some reading!

In your comment, you mention using multi, but the sample you provided uses virtual keys, switch and input-history.

1. What would a multi implementation look like?
2. What are the tradeoffs between either approach?
3. Would either solve the issue of combos that use the shift keys + other modifiers only working if shift is held first?

[jtroo]

The sample configuration does use multi, just need to scroll down 😅 the default text-box size is (in)conveniently perfectly hiding that there is more configuration left to see.

[riotrah]

Hi! I finally got around to trying this out.

It indeed does work such that I can immediately start horizontal scrolling (example use case) with the mousewheel the moment I've started holding down lsft, thanks for that.

However, it now emits the opening paren once I let go of lsft, which means I type a ( into any active input every time I finish horizontally scrolling now.

Also is there a way to still have the timeout? So I don't have to worry about "safely" releasing lsft?

I'm sorry if I'm putting the onus on you haha 😅 there are so many (impressive) additions since I last dived into the docs at this point, including all this exciting iov2 and scancode stuff ( that I don't know how to learn more about)!

[jtroo]

There's no input-timing (yet) but you can use key-timing with recency = 1, which will check against the lsft, if that has still been the most recent key press.

Simulator

[riotrah]

Ah, yet another useful API. Will try that.

How about the mousewheel issue (where holding shift + using mouse wheel still emits a ()?

[jtroo]

Without interception there is currently no way to know that a mouse wheel activation happened; so you'll have to rely purely on the timeout. A short enough timeout and some practice to ensure shift lingers a little longer when intending to scroll horizontally is probably the best solution.

[riotrah]

Ah ok, thanks for the explanation.

At the risk of defocusing this discussion:

1. Could the other windows variants (iov2, scancode) ever help with the mousewheel thing?
2. Either way, where can I learn more about them and how they differ from the regular windows kanata I've been using?

[jtroo]

1. Theoretically any non-interception kanata variant can check mouse events via the WH_MOUSE_LL hook but it is not implemented
2. The links in Windows release docs would be good places to start. https://github.com/jtroo/kanata/releases/tag/v1.6.1