Has anybody had success with TapHold on the home row keys?

dit7ya commented 4 years ago

I have tried different kinds of time thresholds for binding a,s,d,f and j,k,l,; to ctrl, super, alt, meta but nothing has worked reasonably well.

I would like to know if somebody has a setting or workaround for using any of the main alphabet keys as taphold keys.

The problems I have faced

- when I type these taphold keys as normal keys in quick succession some weird things happen and it seems like all these modifier keys are in a held state even long after releasing them.
- I set up both `a` and `;` as shifts. Now typing `A` and `:` requires very precise timing on my end, otherwise it does not get registered.

terlar commented 4 years ago

Sounds like the same thing I experienced: https://github.com/david-janssen/kmonad/issues/26

Didn't find a satisfactory solution for myself

david-janssen commented 4 years ago

There are some race conditions in the current (master) version that perhaps you are running into. Check if it matches any of the #26 symptoms.

I have a completely redesigned kmonad almost ready to publish that has all but eliminated any race condition (that I could find), I just have to put the final touches on some of the parsing of the config files. Having trouble finding the time to get to it though. If you are happy to compile your own kmonad (and are on linux), see if the refactor branch works for you.

dit7ya commented 4 years ago

I have compiled the refactor branch from source and I would say the behavior has reduced in number (but still exists) and I can almost use it. Gonna report again after a few days. Also, what is the time delay that works for you? I have set it up at 200 ms but that still produces some accidental modifiers if type very fast. However, if I reduce it to less than 100 ms my keyboard rarely detects the modifiers. I am curious if there is some adjustment I can do to my keyboard driver or something which would help me find the sweet spot.

dit7ya commented 4 years ago

Update: I don't think its usable even after not using the home-row keys as modifiers. Currently I am using only caps lock and return as TH keys but have experienced the same weird behavior twice in last two hours.:disappointed:

dit7ya commented 4 years ago

Oops, sorry. I think though I had compiled the refactor branch I have been using the master one's binary so far. However, now when I try to launch kmonad with the kmonad start config.kbd it throws the error

1 | /*                                     IO
  | ^
unexpected '/'
expecting '(' or end of input

wismill commented 4 years ago

It seems the format has changed https://github.com/david-janssen/kmonad/blob/refactor/doc/example.kbd

dit7ya commented 4 years ago

@wismill Yeah just figured that out! I could not find any documentation though for the new format though, for example, I don't understand the syntax for macro-sequence shortcuts. Shifting this to Lisp is a good idea though - much easier to use code highlights now.

Will report back if I face any race conditions in the refactor branch.

david-janssen commented 4 years ago

Hey there,

Sorry I didn't manage to provide better support, I should've mentioned all the changes. Very preoccupied and busy these last few days. Hope to get to it soon. Thanks for experimenting with the refactor version, and all the best.

I will leave this open for a bit, feel free to close it if the refactor branch is working for you.

Cheerio,

D

scottrosenquist commented 4 years ago

Hey, this sounds very similar to the issue I was having with issue #16. I'm currently on the refactor branch and from my experience it functions basically the same as my QMK keyboard, home row tap-hold mods and all.

Here's the config I'm using https://github.com/scottrosenquist/.dotfiles/blob/master/common/.config/kmonad/thinkpadhomerowmods-refactor.kbd

I've been using this since March 14th as my laptop keyboard. Allows me to transition back and forth from my mechanical keyboard seamlessly.

dit7ya commented 4 years ago

@scottrosenquist Thanks for your comment. I am planning to give your config a try soon.

@david-janssen No reason to be sorry! Massive thanks to you for already providing such a brilliant FLOSS software.

Here's another issue I am experiencing. Seems like tap-hold keys cannot register if I tap too quick. I was using left and right shift for tap holds for ( and ) but it seems like it requires more than 200 ms to register a hold. Before discovering kmonad I was using xcape and that works fine for me with even longer time delays like 250 ms.

Is it possible that a longer time delay is somehow hardcoded in the source?

Here's my current config if that matters.


;; Define the IO parameters of this keyboard
(defcfg
  input  (device-file "/dev/input/event4")
  ;; output (uinput-sink "KMonad: Atreus" "/run/current-system/sw/bin/sleep 1 && /run/current-system/sw/bin/setxkbmap -option compose:ralt")
  output (uinput-sink "KMonad: Shenanigan")
  ;; init   "/usr/bin/sleep 1"
  )

;; ;; Define layer toggling shortcuts
(defalias
  ;;   smb (layer-toggle symbols)
  ;;   ;; hsk (layer-toggle haskell)
  ;;   ;; fun (layer-toggle funckeys)
  ;;   alt/ (tap-hold 200 / lalt)
  xcp (tap-next esc lctl)
  xsp (tap-hold 200 C-M-esc lmet)
  sa  (tap-hold 200 a lsft)
  ss  (tap-hold 200 s lctl)
  sd  (tap-hold 200 d lalt)
  sf  (tap-hold 200 f lmet)
  s;  (tap-hold 200 ; rsft)
  sl  (tap-hold 200 l rctl)
  xrt (tap-hold 200 ret rctl)
  ls (tap-hold 250 \( lsft )
  rs (tap-hold 250 \) rsft )

  ;; sa = TH 200 a lsft        // a when tapped, shift when held
  ;; ss = TH 200 s lctl        // s when tapped, ctl when held
  ;; sd = TH 200 d lalt        // d when tapped, super when held
  ;; sf = TH 200 f lmet        // f when tapped, alt when held

  ;; s; = TH 200 ; rsft        // ; when tapped, shift when held
  ;; sl = TH 200 l rctl        // l when tapped, ctl when held
  ;; // @sk = TH 150 k ralt        // k when tapped, super when held
  ;; // @sj = TH 150 j rmet        // j when tapped, alt when held

  ;; xcp = TH 200 esc lctl      // Escape when tapped, control when held
  ;; xrt = TH 200 ret rctl      // Escape when tapped, control when held
  ;; xsp = TH 200 C-M-esc lmet
  ;; @num = LT-numpad            // Switching to the numpad layer
  )

;; Define macro-sequence shortcuts
(defalias
  >>= #(> > =)
  ->  #(- >)
  <-  #(< -)
  <*> #(< * >)
  <$> #(< $ >)
  =>  #(= >)
  sml #(: - \))
  wnk #(; - \))
        :p  #(: p)
        )

  ;; Define the input-layout coming from the keyboard
  (defsrc
    esc  f1   f2   f3   f4   f5   f6   f7   f8   f9   f10  f11  f12  ins  prnt  del
    grv  1    2    3    4    5    6    7    8    9    0    -    =    bspc         home
    tab  q    w    e    r    t    y    u    i    o    p    [    ]    \            pgup
    caps a    s    d    f    g    h    j    k    l    ;    '    ret               pgdn
    lsft z    x    c    v    b    n    m    ,    .    /    rsft up                end
    lctl      lmet lalt           spc            ralt compose rctl  left  down    rght
    )

  (deflayer alpha
    caps f1   f2   f3   f4   f5   f6   f7   f8   f9   f10  f11  f12  ins  prnt  del
    grv  1    2    3    4    5    6    7    8    9    0    -    =    bspc         home
    tab  q    w    e    r    t    y    u    i    o    p    [    ]    \            pgup
    @xcp @sa  @ss  @sd  f    g    h    j    k  @sl    ;    '    @xrt              pgdn
    @ls  z    x    c    v    b    n    m    ,    .    /    @rs  up                end
    lctl      @xsp lalt           spc            ralt compose rctl  left  down    rght
    )

david-janssen commented 4 years ago

Here's another issue I am experiencing. Seems like tap-hold keys cannot register if I tap too quick. I was using left and right shift for tap holds for ( and ) but it seems like it requires more than 200 ms to register a hold. Before discovering kmonad I was using xcape and that works fine for me with even longer time delays like 250 ms.

Not sure I follow: are you saying that you are specifying a 250 delay, but it is still behaving like a 200 delay? That would be very strange. It should work for any length of delay. If that isn't the problem, explain to me again what the issue is?

dit7ya commented 4 years ago

Sorry, I simply mean that even though I set a delay of 250, I get an actual delay which is longer (or shorter? I am confused).

Here's an example. With my normal typing speed and xcape, when I press Shift + ; I usually get :. But with kmonad I have been mostly getting (; even though in both cases the delay is 250.

david-janssen commented 4 years ago

There is a small difference between the implementation of TapHold buttons between kmonad and QMK. kmonad will try to detect the release of the TapHold button within the interval (pausing all other processing). If the release is detected, a tap is emited, and then processing is unpaused on subsequent input, if the delay is exceeded, the press of its 'held' button is emitted, and then processing is unpaused.

To clarify assume the following situation:

TH 250 x sft mapped to the X key
y mapped to the Y key

Then the following sequence could play out:

0ms: Press X (Further processing is paused until the tap-hold situation is resolved)
100ms: Press Y (This event is held for a moment until we know what the tap-hold is doing)
200ms: Release X (This resolves the TapHold as a Tap (200 < 250), so we emit a tap of X, and immediately process any further events (also causing the press of the Y to register and be emited))

(result: xy)

Or, alternatively:

0ms: Press X (Further processing is paused until the tap-hold situation is resolved)
100ms: Press Y (This event is held for a moment until we know what the tap-hold is doing)
250ms: Delay expires (This resolves the TapHold as a Hold, so we emit a press of Shift, and immediately process any further events (causing kmonad to emit the press of Y)
400ms: Release X (Since X resolved to it's held status, it functioned as an emitter of Shift, so now we send the release of Shift)

(result: Y) Does my explanation make sense?

This, btw, was a design feature. I had trouble with QMK style TapHold buttons mapped to keys that I would strike very quickly (they work fine for modifiers like Ctrl, but when I mapped onto homerow keys, for example, I would very often get the wrong key), and this method of specifying the delay on the release of the button, not on the strike of another button, worked better.

Or if you just want the practical suggestion: I think (think) that QMK will resolve a TapHold the moment another key is pushed, whereas kmonad tapholds will pause and restart processing only when these decisions are made: ergo, the delay points at when you release the taphold, not when you press the next button: ergo, experiment with shorter delays :-).

xcapegoat commented 4 years ago

I possibly have the same experience as dit7ya. I have ; as a taphold (shift and return). Since I often hit shift --> whateverkey so fast, to adjust for this the timer seemed a bit like it would have to lowered to such a degree that return would be difficult to press fast enough.

According to how I'm used to it in xcape, if ; and whateverkey are hit "together", it seems like the whateverkey would get shifted, regardless of whether it was in the time delay before shift is alone enabled, and the tap would only emit upon a key up event. I know I'm probably wrong about how xcape works.

For me this situation has not been such a big deal however. I'm using TH 170 at the moment and 200 for my space bar. I think I can see the logic in your description...I think this feature of yours is enabling me to type faster with my taphold on space (which I had since a few months ago when I was still using xcape.

Actually I think I suggested something vaguely similar to this (?) for xcape a few months ago on my old account:

forgetmenotz commented on 19 Feb • 
I had an idea that I thought might be able to solve this issue for
those of us who hit the space modifier too often. If an xcape
modifier could be set to disabled until a certain time after other
keys are pressed, say some amount of milliseconds, it might
prevent the unwanted modified keys while typing, but remain
useful when not typing. Anyone think it could work? I'm not sure.

Edit: tapnext solves my problem with shift.

david-janssen commented 4 years ago

Just to make sure I understand:

The TapHold is a little bit nicer for you with your spacebar, so that is just a good thing.
It made using shift a little harder, but that problem is fixed with TapNext

So, winwin?

If so: feel free to close the topic. If not: can you clarify your issue because I cannot see your question at the moment :-)

EDIT: Oh wait, it's not your topic! I will wait for @dit7ya to close then

xcapegoat commented 4 years ago

Yes problem solved on both accounts. I didn't mean to write so much, but developments happened while I was writing. It might be a different issue for others.

david-janssen commented 4 years ago

Happy to hear it's solved! :-)

I didn't mean to write so much, but developments happened while I was writing. It might be a different issue for others.

No worries, you did nothing wrong.

david-janssen commented 4 years ago

Closing this now because if I understand correctly everyone who has tried 'refactor' is happy with how things are working? Feel free to object.

kmonad / kmonad

Has anybody had success with TapHold on the home row keys? #32