Skip home row mods while typing

[argenkiwi]

I though I would share an alternative to #1425 which consists of skipping the home row modifiers while typing:

(defcfg
  process-unmapped-keys yes
)

(defsrc
)

(deftemplate charmod (char mod)
  (switch 
    ((key-timing 3 less-than 450)) $char break
    () (tap-hold-release-timeout 200 500 $char $mod $char) break
  )
)

(deflayermap (main)
  a (t! charmod a lmet)
  s (t! charmod s lsft)
  d (t! charmod d lctl)
  f (t! charmod f lalt)
  j (t! charmod j lalt)
  k (t! charmod k rctl)
  l (t! charmod l rsft)
  ; (t! charmod ; rmet)
  v (t! charmod v ralt)
  m (t! charmod m ralt)
)

In essence, we use switch to check a key-timing condition that evaluates the elapsed time since a key, determined by the key-recency, has been pressed. By setting the key recency to the maximum number of modifiers we will hold at any given time, we make sure our chords work as expected.

I will experiment more with this approach when I am back at work using it in real world scenarios, but early testing looks promising!

UPDATE: I have added a defcfg block and set process-unmapped-keys to yes (see comment below).

[argenkiwi]

A bit if context: I commented on the discussion mentioned above that project keyd has an action overloadi that basically allows you to emit a different key or action depending on whether a symbol or character has been emitted during a specified timeout. @jtroo gave me some pointers on how to achieve this using switch, as seen above. I think the main difference here is that we are dealing with keys instead of characters, which is why it is important to set the correct value for key-recency.

I came across a video about home row modifiers that features Kanata and I could see most comments criticize the tool because the implementation the content creator demonstrates is the most basic one: tap-hold. Hopefully providing good examples of better alternatives will persuade some of those commenting of the quality and power of this piece of software.

[gerhard-h]

early testing looks promising

Agreed :) The simplicty is stunning. I tried it while also getting rid of the time pressure from tap-hold-release-timeout
(by doing this I also disabled all kinds of autorepeat, but I dont use autorepeat for letter keys anyway)

(deftemplate homerowmod ( timeouthold char mod)
  (switch 
    ((key-timing 3 less-than 140)) $char break
    () (tap-hold-release 0 $timeouthold  $char $mod) break
  )
)

I kept my old per-key-timings for $timeouthold, but adjusting the numbers in key-timing 3 less-than 450 took me some time.

Learnings so far:

• key-timing 3 must not only account for number of modifiers in shortcuts but also the longest chordsv2 in the homerow
• less-than 450 can be reduced to less-than 140 (that is even less then minimum of all my $timeouthold's) without loosing its functionality. But only now shift becomes responsive enough for me.
• in the past I prefered tap-hold but here tap-hold-release is important (for single mod shortcuts to be responsive)

I will also keep testing this.

[argenkiwi]

Thanks for sharing your learnings! I'll give those tweaks a go when I have a chance.

What I am still not sure about the example is whether process-unmapped-keys needs to be set to yes. I use deflayermap instead of deflayer in my layout, and I tested this on Linux. It did not seem to matter. But maybe it does affect other configurations or platforms.

UPDATE: it appears to be necessary, as the documentation suggests, or at least all keys used for typing (i.e., letters, numbers, symbols and space) should be added to defsrc so they are registered by the key-timing logic.

[argenkiwi]

I was thinking of a potential optimisation I will try tomorrow when I'm back at work: what if we used different key recencies for the modifiers depending on how we roll our chords? For example, if you distribute shift, control and alt in that order on your home row then you could use 1, 2 and 3 as their respective recencies as long as you make sure to roll your fingers over the keys in the same order. My hypothesis is that you could more granularly regulate the time for each key-timing which could improve the usability of shift as a home row modifier while typing, for example.

[TZProgrammer]

I love the approach. Has this been tested in a more programming-focused context, where mod keys might be used more often while intertwined with typing? For example, I commonly find myself pressing the modifier for the symbol layer after a spacebar while programming. Would there be a way to allow home row mods after certain special keys, or would this not be necessary in the first place?

[argenkiwi]

I have a feeling @gerhard-h has spent more time stress-testing this approach than myself (see his recommendations above). In terms of using multiple modifiers, that is the first problem I had to deal with and I addressed it by adjustin the key recency to match the maximum number of modifiers hjttI would need at a given time (that's what the 3 next to key-timing stands for). You may want to adjust the value to your specific needs.

[TZProgrammer]

I went back and noticed the key-timing looked at the third last key. That's a brilliant solution! I had not caught that at first. I will definitely tinker around with this.

[argenkiwi]

From the docs:

The key recency must be in the range 1-8, where 1 is the most recent key that was pressed and 8 is 8th most recent key pressed. Most use cases are expected to use a value of 1 for this parameter, but perhaps you can find a creative use for the other values.

@jtroo must have had a gut feeling it could be put to good use. 😂