Support one-shot and double tap shift simultaneously

[argenkiwi]

The problem I observed is that, after adding one-shot support to one of the shift keys, I can no longer use the double tap gesture on that key, which happens to be a very common shortcut on IntelliJ-based IDEs to perform a general search. I presume it is because technically you can't tap shift again if it is already being held.

At the moment I simply use left shift for one-shot and right shift for double tap, which is alright. However, one of the main principles behind my keyboard layout is to make it so anyone using my machine should not notice it is there unless told, but they will notice something is off if double shift does not work as intended.

Thanks in advance for your advice on how to solve this in the simplest way possible.

[gerhard-h]

you can combine double tap and one-shot
simulate

[argenkiwi]

Thanks! Your solution using tap-dance combined with one-shot and macro seems to work very nicely and looks pretty simple to me. I only had to increase the timeouts a bit (my double tap is too slow and my one shot even slower 😄).

[argenkiwi]

I tested this for a day. It seems a side effect is that if I hold shift to select multiple lines of text (i.e., pressing up or down) it tends to skip a line. I guess getting the timing right is the ticky part.

[jtroo]

This solution might work better if you change rapid-event-delay to a number higher than the default 5.

https://jtroo.github.io/config.html#rapid-event-delay

It's not described but this should also apply to tap-dance activations.

[gerhard-h]

maybe tap-dance-eager solves your timeing issues
here an example
sim there is an additional shift release (without press before) if that causes problems you may have to use virtual-keys or one-shot-release-pcancel also looks good

[argenkiwi]

I am now trialing a slightly different approach: I created a layer called shift which makes use of tansparent key and multi to bind all unmapped keys while setting the shift keys to double tap using macro.

Here is a full sample of the configuration:

(defcfg
  process-unmapped-keys yes
)

(defsrc
)

(deflayermap (shift)
  lsft (macro lsft lsft)
  rsft (macro rsft rsft)
  __ (multi lsft _)
)

(deflayermap (main)
  lsft (one-shot 2000 (layer-while-held shift))
  rsft (one-shot 2000 (layer-while-held shift))
)

Using chords with transparent key does not seem to work (i.e., S-_). I wonder if that is something that could be supported.

[jtroo]

Presumably you want it as output chord due to the eager lsft release on following key press? The behaviour could probably be added as an option to multi more easily than supporting S-_.

[argenkiwi]

I was just curious, I probably won't need chords for my use case.

EDIT: I see what you mean. I observed sometimes instead of getting one character capitalized I get two if I type quickly (e.g., TEst).

[argenkiwi]

I've just found another problem with the approach: shift + click to select text up to the mouse cursor position stops working. 😞

[jtroo]

Does this work: simulator link

(defsrc lsft)
(deflayer base
 (fork (one-shot-press-pcancel 2000 lsft)
       (macro nop0 30 lsft)
       (lsft)))

[jtroo]

An unfortunate consequence of this solution is that holding the second tap doesn't keep the key held down. And then due to the way one-shot is implemented, using other tricks like virtual keys with on-release doesn't seem possible either, because the lsft input itself is forcefully released when one-shot is deactivated; even if the second lsft input has a different associated action.

[argenkiwi]

I am now trying a different approach without using one-shot but using virtual keys instead, as @gerhard-h had previously suggested:

(defcfg
  process-unmapped-keys yes
)

(defsrc
)

(defvirtualkeys
  shift (multi (layer-while-held shift) lsft)
)

(deflayermap (shift)
  lsft (macro (on-press release-virtualkey shift) 50 lsft)
  __ (multi _ (on-press release-virtualkey shift))
)

(deflayermap (main)
  lsft (tap-hold-press 200 200 (on-press press-virtualkey shift) lsft)
)

The only main caveat is that there is no time-out for this pseudo-one-shot. I tried using on-idle to release the virtual key after a timeout, but I might not understand how to use it correctly. I saw in the docs we will soon have hold-for-duration, maybe that will do the trick. Also, if you shift and then click to select text up to the cursor it sometimes does not perform the selection.

[gerhard-h]

since your vkey shift is down on-idle never triggers.
but you can make your own timer vkey

with sft you also press on-idle-action wich waits for 500ms before doing something
on-idle-action (macro-release-cancel 500 (on-press release-virtualkey shift))

together with your release-virtualkey shift you also

(on-... release-vkey on-idle-action) to clear the timer

maybe on-idle-action should also clear itself
on-idle-action (macro-release-cancel 500 (on-press release-virtualkey shift)(on-press release-virtualkey on-idle-action))

there is a thread about this
#1254

[jtroo]

On-idle vkey can't clear itself because Kanata doesn't support self or forward references today. It's been somewhat intentional to avoid unintended infinite recursion.

[gerhard-h]

@argenkiwi I updated my original comment #1254 (comment) on how to do timers

[argenkiwi]

Thanks for your help @gerhard-h and @jtroo. Sorry for the delay. It took me a while to get my head around adding the timer concept into the mix. This is what I've got so far.

The Shift + Click for text selection issue persist, which is not a big deal. I suppose clicks are not captured by the transparent key wildcard (__) tap-hold-press. But the rest seems to work as expected. I'll be testing it in the real world today.