Home row mods and automatic fast typing layer

[gerhard-h]

The idea of a fast typing layer is, that every short tap of a letter will automaticly activate a layer without home row mods

There are already threads on this topic, but I wasn't able to find them, so I decided to start a new thread with a working solution at the top.

(defcfg
process-unmapped-keys yes 
)
;; Problems with home row mods (asuming QUERTY and shifting with index fingers)
;; P1 unwanted mod activation (this is the big problem)
;; P2 shifted rolls [ER instead of Er] (human not fast enought to release shift in time) 
;; P3 shift finger overload [fof or fo instead of Of] (human releases shift to early to speed up the follow up f) 

;; Solution (status)
;; P1 solved by fast typing layer (and by higher hold-timeouts for non shift modifiers)
;; P2 solved by using unmod in fast typing layer (has the side effect that ALL CAPS words must be typed without activating this rolls) 
;; P3 only solved for FJ - other cases require learning the correct timeing

;; timeings should work fine for 40 to 80 words per minute; if you are slower or new to home row mods increasing them might help in getting started   

(defvirtualkeys
to-base (layer-switch base)
)

(defvar
  tot 220  ;; setting this to 0 could in theory improve delays 
)


(deftemplate homerowmod (timeouttap timeouthold keytap keyhold)
	(tap-hold $timeouttap $timeouthold 
		(multi $keytap  @.tp) 
		$keyhold
	)
)

(defalias
  .base   (layer-while-held base)
  .tp  (multi
    ;; (layer-switch typing) ;; causes a P3 issue with Ffj instead of FJ         
	(one-shot 95 (layer-while-held typing)) ;; solves P3 only in the FJ case
    (on-idle  95 tap-vkey to-base )
  )
)

(defsrc )

(deflayermap (base)
 f (t! homerowmod $tot 160 f lsft)
 j (t! homerowmod $tot 160 j rsft)
 d (t! homerowmod $tot 300 d lctl)
 k (t! homerowmod $tot 300 k rctl)
 s (t! homerowmod $tot 400 s lalt)
 l (t! homerowmod $tot 400 l ralt)
 a (t! homerowmod $tot 450 a lmet)
 q (multi q @.tp) w (multi w @.tp) e (multi e @.tp) r (multi r @.tp) t (multi t @.tp) y (multi y @.tp) u (multi u @.tp) i (multi i @.tp) o (multi o @.tp) p (multi p @.tp) g (multi g @.tp) h (multi h @.tp) z (multi z @.tp) x (multi x @.tp) c (multi c @.tp) v (multi v @.tp) b (multi b @.tp) n (multi n @.tp) m (multi m @.tp) 
)

(deflayermap (typing)
 a (unmod a) b (unmod b) c (unmod c) d (unmod d) e (unmod e) f (unmod f) g (unmod g) h (unmod h) i (unmod i) j (unmod j) k (unmod k) l (unmod l) m (unmod m) n (unmod n) o (unmod o) p (unmod p) q (unmod q) r (unmod r) s (unmod s) t (unmod t) u (unmod u) v (unmod v) w (unmod w) x (unmod x) y (unmod y) z (unmod z) 
)

[thomastthai]

@gerhard-h, I've read many of your posts and comments in my research to understand Kanata. You have a talent for explaining somewhat complex concepts and ideas in an easy-to-understand yet succinct way. Thank you for your contributions.

Nice touch using unmod in the "fast" typing layer with your config!

[thomastthai]

I'm testing your config with minimal changes and will let you know how I'm doing. I moved the modifier keys down one row because, in past tests, those keys were used less to mitigate unintended key combinations. The order in which my modifier keys are set up is the same as yours.

I have an nvim plugin that updates the current layer and reports Kanata TCP server status changes. As expected, with the frequent layer changes for each key tap, the layer status update lags significantly behind when typing a sentence. Depending on how long the sentence is, it could take up to around 5+ seconds to catch up.

The finger-roll issue is still present but minimal after a short period of typing tests. For example, typing 'achieve' will result in 'achieE'. My left index finger curls back to press the v key while the left middle finger presses the e key. The split movement between the v and e keys and the forward movement of the left middle finger puts pressure on the left index finger keeping the v key down and delaying its release. Another example is 'movement' results in 'Ovement'.

Even though the index finger is stronger and can move faster than the other fingers for most key combinations, it's pretty slow when curled back, especially with the following key press stretching another finger on the same hand forward. For my setup, extending the hold time for the shift keys v and m to longer 300 ms helped.

[gerhard-h]

I never tried tap-hold-except-keys before but it seems to solve the issue

or try this and experiment with the 50ms timeout in

(defchordsv2
  (v e) (macro v e ) 50 all-released  ()
)

P.S. whats your typing speed?

P.S2. Using bottom row mods because home row mods have issues doesn't feel right in a thread that claims all home row mods issues can be solved :)

P.S3. I once tested how fast I am with

1. space-bar-shift (clear winner)
   2/3. homerowF-shift or bottomrowV-shift (not much of a difference)(ortholinear keyboard)
2. homerowD-shift (realy slow)
3. shiftkey-shift (looser)

[thomastthai]

My home and bottom row mods configs originated from @jtroo's home-row-mod-advanced.kbd. Some of them use tap-hold-except-keys and defchordsv2 to solve some issues that required more bias toward tap versus hold. I'll reintegrate them with your ideas after further test of your ideas.

About:

• P.S. I've not measured my typing speed. It is worth doing to test different setups to measure the effectiveness of my typing.
• P.S2. Agree. I used home row mods for a long time. I changed to bottom-row mods because my other layers heavily use the home row for other keys and still need the modifiers. The core principles remain similar.
• P.S3. I've not tried shiftkey-shift and don't think I will. I settled on putting the shift modifier responsibility on the index fingers because they are stronger, move faster, have more range not blocked by other fingers, and are agile. The middle fingers were decent for me as shift modifiers when I used home row mods. When moving to bottom row mods, the middle fingers were slow due to the curl to reach the c or ,.

[thomastthai]

Typing 'WORD' (all caps) fast results in 'WorD' or sometimes 'WOrD' with the right index finger holding down the shift modifier key j for home row mods or m for my bottom row mods. Typing slowly to ensure each key is succinctly tapped results in 'WORD'.

What I think happens when typing fast that results in 'WorD':

1. Start with the base layer active.
2. The right index finger holds down the shift modifier.
3. w is pressed with the left ringer finger and registers 'W'.
4. The one-shot action activates the typing layer through layer-while-held. unmod in the typing layer prevents letters in the typing layer from being impacted by the modifiers, e.g. shift in this case.
5. Since the left ringer finger is slower to release w, the right ring finger presses o and resets the one-shot timer because it's a consecutive one-shot action and registers 'o' instead of 'O'. Consecutive letters that use the opposite hand can be pressed quickly because of their hand-independence.
6. The left ringer finger on w now has enough time to release, but the slow-to-release right ring finger still has o pressed keeping the typing layer active.
7. The typing layer is still active due to the consecutive one-shot actions and on-idle 95 isn't activated because of the lack of idle for within 95 ms.
8. The quicker left index finger presses r and results in 'r' instead of 'R' because of the above reasons.
9. The right ring finger has enough time to release o key.
10. The left index finger is quick to release the r key' because it's more agile. Additionally, it is shorter in length than the middle left finger so it has to lift to make room for the longer-length left middle finger to move down to press the d key. The quick release of the r key allows 95 ms or more to pass to activate the on-idle 95 to switch to the base layer.
11. The left middle finger presses the d key and registers 'D' because the last umod action restores the state of the shift modifier after its key is tapped.

As for how fast typing results in 'WOrd' is similar to what happened above with the exception that the left ring finger was able to release the w key early enough for the on-idle 95 to trigger the base later allow the o key to be impacted by the shift modifier resulting in O.

Possible Solution

As a test, umod was removed from the typing layer just for those keys. I can type 'WORD' as fast as I can while the index finger presses the shift modifier and it'll come out as 'WORD'. Another option is to allow shift modifiers but limit the others, e.g. instead of (unmod w), use (unmod (lmet lalt lctl rctl ralt rmet) w) for all letters. But this could bring back the issue of finger-roll causing the typing of 'WE' instead of 'We'.

[argenkiwi]

I was going to start a discussion about keyd's approach to this problem. They use an action called lettermod which is a shorthand for combining 2 simpler actions: overloadt2 (i.e., tap-hold-release) and overloadi. The latter allows you to specify a period of time after a character (non-action) is triggered during which a key will be emitted. That means that when a sequence of characters is being typed in quick succession, the home row mod action will be skipped and the key will be emitted immediately. It could be a good addition to Kanata.

[jtroo]

It could be a good addition to Kanata.

Can this be implemented by using switch and key recency timing?

[argenkiwi]

Is it a rhetorical question? 😆 I'll have a look!

[argenkiwi]

(deflayermap (main)
  a (switch ((key-timing 2 less-than 200)) _ break () (tap-hold-release-timeout 200 500 a lmet a) break)
  s (switch ((key-timing 2 less-than 200)) _ break () (tap-hold-release-timeout 200 500 s lsft s) break)
  d (switch ((key-timing 2 less-than 200)) _ break () (tap-hold-release-timeout 200 500 d lctl d) break)
  f (switch ((key-timing 2 less-than 200)) _ break () (tap-hold-release-timeout 200 500 f lalt f) break)
  j (switch ((key-timing 2 less-than 200)) _ break () (tap-hold-release-timeout 200 500 j lalt j) break)
  k (switch ((key-timing 2 less-than 200)) _ break () (tap-hold-release-timeout 200 500 k rctl k) break)
  l (switch ((key-timing 2 less-than 200)) _ break () (tap-hold-release-timeout 200 500 l rsft l) break)
  ; (switch ((key-timing 2 less-than 200)) _ break () (tap-hold-release-timeout 200 500 ; rmet ;) break)
  v (switch ((key-timing 2 less-than 200)) _ break () (tap-hold-release-timeout 200 500 v ralt v) break)
  m (switch ((key-timing 2 less-than 200)) _ break () (tap-hold-release-timeout 200 500 m ralt m) break)
)

Is that it? It seems to work great! I hope I am not breaking something else, but I have not found any issues. Thanks @jtroo!

EDIT: I adjusted the key recency to 2 which will allow me to do chords of 2 modifiers plus another key. If you do chords with more keys, you will have to adjust the key recency for the key timing.

[thomastthai]

I've tried many solutions for home row or bottom row mods but haven't tried switch with key-timing yet! @argenkiwi, good idea to share that concept from keyd and get @jtroo's input about switch with key-timing. What issue, if any, did you run into with this solution?

[MaskRay]

As a newcomer to Kanata and home row mods, I've configured (asdf jkl;) and chord (jk) for esc, but am still adjusting to the workflow.

I have encountered these issues:

• Dual-purpose a: Rapid typing after a can lead to key repetition (e.g., 'kanata' becoming 'kannatta'). @gerhard-h's suggestion of a longer delay for a (around 400ms) seems effective.
• Repeating j/k is useful in applications like neovim, less, and cgdb. I switched to tap-hold-press-timeout to enable j/k repetition while introducing a slight initial delay.
• In neovim, I map <space><space> to require('telescope.builtin').buffers and <space>sp to a search project function. <space>sp sometimes triggers <space><space>sp (open buffers and then type sp).
  I cannot consistently reproduce this currently. https://maskray.me/blog/2024-11-02-tinkering-with-neovim
• In neovim, I map x to <Nop> and xd to <cmd>CclsDerived<cr> (find derived classes/functions). If I do not tap d rapidly, d will trigger the default function and wait for a motion key.
• Typing ke rapidly might trigger ctrl-e . This example is from http://xahlee.info/kbd/multi_purpose_keys.html

This thread is valuable, but I'm having trouble understanding problems P2 and P3 due to unfamiliar terminology. Could you elaborate on them?

Anyway, the all-caps words typing issue (tapping other keys while holding j/rsft) might not be crucial for me. Regardless, I'll continue following this thread.
Thanks for the fruitful discussion:) Hope that someone will summarize these and give a write-up :)

---

I am currently using a config like:
Thanks to @argenkiwi for the switch+key-timing idea.

(defcfg
  concurrent-tap-hold yes
  log-layer-changes no
  process-unmapped-keys yes
)
(defvar
  tt 200 ;; tap-time
  ht 160 ;; hold-time
)

(defalias
  tab (tap-hold $tt $ht tab (layer-while-held extend))
  cap (tap-hold $tt $ht esc lctl)
  ;; cap (tap-hold $tt $hold-time esc (layer-while-held vim-nav))
  a (switch ((key-timing 1 less-than $tt)) _ break () (tap-hold $tt $ht a lmet) break)
  s (switch ((key-timing 1 less-than $tt)) _ break () (tap-hold $tt $ht s lalt) break)
  d (switch ((key-timing 1 less-than $tt)) _ break () (tap-hold $tt $ht d lctl) break)
  f (switch ((key-timing 1 less-than $tt)) _ break () (tap-hold $tt $ht f lsft) break)
  j (switch ((key-timing 1 less-than $tt)) _ break () (tap-hold-release-timeout $tt $ht j rsft j) break)
  k (switch ((key-timing 1 less-than $tt)) _ break () (tap-hold-release-timeout $tt $ht k rctl k) break)
  l (switch ((key-timing 1 less-than $tt)) _ break () (tap-hold $tt $ht l ralt) break)
  ; (switch ((key-timing 1 less-than $tt)) _ break () (tap-hold $tt $ht ; rmet) break)
)

(defsrc
  tab  q    w    e    r    t         y    u    i    o    p    [
  caps a    s    d    f    g         h    j    k    l    ;    '
  lsft z    x    c    v    b         n    m    ,    .    /    rsft
)
(deflayer default
  @tab _    _    _    _    _         _    _    _    _    _    _
  @cap @a   @s   @d   @f   _         _    @j   @k   @l   @;   _
  _    _    _    _    _    _         _    _    _    _    _    _
)
(deflayer extend
  _    _    _    _    lrld _         _    C-S-tab C-tab  _    _    _
  _    _    _    _    _    _         left down up   rght _    _
  _    _    _    _    _    _         home pgdn pgup end  _    _
)

(defchordsv2
  (j  k     ) esc 100 all-released ()
  (   k  l  ) =   100 all-released ()
  (j     l  ) S-= 100 all-released ()
  (      l ;) -   100 all-released ()
)

---

@xahlee kanata might be nice to mention on http://xahlee.info/kbd/multi_purpose_keys.html

[argenkiwi]

No worries! Thank @jtroo for the idea, just sharing my implementation here. You may want to adjust the key-recency for key-timing to allow for chords with more than 2 keys using home row modifiers (see my updated comment above).