search

jtroo / kanata

Improve keyboard comfort and usability with advanced customization
GNU Lesser General Public License v3.0
2.23k stars 112 forks source link

Doc improvement: when are chords released? #403

Closed prescientmoon closed 1 year ago

prescientmoon commented 1 year ago

It's not clear from the docs if input chords are released when one of the keys gets released, or if they are released when all the keys have been released. This distinction is very important to me, and it would help me decide whether this project is what I'm looking for!

gerhard-h commented 1 year ago

I have this basic chord and it fires e as soon as 0 and < keys are both down

(defchords acord 300
  (0      ) 0
  (   <   ) <
  (0  <   ) e 
)

in most cases I force chords to only fire if the key(s) is just tapped a{ (tap-hold 140 140 @chorda @{ ) not sure that helps with your usecase

prescientmoon commented 1 year ago

@gerhard-h My question was about when the chords get released, not when they get pressed.

gerhard-h commented 1 year ago

meanwhile I changed my config to not autorepeat chords anymore, so for me cords just end, regardless of (pysical) key up events.

jtroo commented 1 year ago

It's a little more subtle and perhaps surprising.

Before the timeout period ends, a release of any key will trigger chord activation.

When no releases occur before the timeout expires, a chord ends when the first key pressed (which might be hard to know which that was) is released.

I'm curious what behaviour you're looking for and how the difference affects your use case.

prescientmoon commented 1 year ago

@jtroo The behaviour I want is the chord being held down until all keys have been released.

Example of my current setup: jl for control gh for backspace => I can press jl, release j (control is still being held!) and then press gh. This deletes the previous word in most environments, and feels very satisfying to perform!

Right now I use my own utility which does chording only, but I'd be hyped to switch to this given the chance.

jtroo commented 1 year ago

Thanks for the info! Kanata does not currently behave this way, but it seems like it might be useful to potentially configure at as such.

jtroo commented 1 year ago

I believe the code change in #406 should satisfy the use case.

I haven't made it configurable, but instead recommend in the documentation to use macros for chords in case the user wants to turn off the new hold/release behaviour. I would hope nobody is relying on the existing - hard to use and understand - hold/release behaviour for their use cases, so that this change doesn't break anyone. I suppose they could just stick to v1.3.0 though, if they try out the new code and it breaks their workflows.

I haven't tested it by hand, but a unit test was adjusted for the new behaviour and seems like it should work.

prescientmoon commented 1 year ago

Thank you very much for the awesome project @jtroo ! Can't wait to start using it now that this is fixed!