Repeat key limitation?

[drivermix]

Hello!

L{J} >> Left
J{L} >> Right

If I hold L{J}..... I get the Left key to repeat as expected, which is exactly what I want. But when I hold J{L}, the Right key doesn't repeat. Incidentally, if I switch the order of these two declarations, again... only the first declaration produces the repeat effect. I need them both to repeat without any issues.

I hope someone could suggest a workaround.
Thanks in advance!

[houmain]

This works now with the 4.12.0 release.

[drivermix]

Thank you so much! Keep up the good work!

[drivermix]

I hope you don't mind my adding on to an already closed discussion. I couldn't find a way to re-open it. :)
Well, the thing is that while the new version of keymapper fixes the above example... in a slightly different setup, repeat action fails again.

K{J} >> Left
K{L} >> Right

On its own, each combo works fine; I get the expected repeat action from both. But let's say I'm going left by holding K{J}, and then suddenly decide to move right, I should be able to just let go of J, and with K still held down, simply press-hold L to move right. But this suddenly breaks down repeating action, and I can't repeat-move in either direction unless I let go of K and start again.

I must mention, however, that with a similar setup...

Alt{J} >> Left
Alt{L} >> Right

I can hold the Alt key and then press-hold J or L for however long I need in order to quickly move the cursor back and forth. Alt as a 'shared' modifier works great. But I've been trying to come up with and move to a more intuitive home row setup that doesn't require the use of Alt key for this purpose, and this is how I've discovered these issues.

I hope this issue can be worked out programmatically.
Thanks in advance!

[ristomatti]

This might have unexpected side effects, but based on quick testing I was able to get back-and-forth movement with this config:

[modifier = "K"]
  J >> ArrowLeft
  L >> ArrowRight

[default]
  K{!100ms} >> K
  K         >>

[houmain]

@ristomatti Cool idea!

I just pushed a version 4.12.1, which fixes key repeats also in configurations like:

L{J} >> ArrowLeft
J{L} >> ArrowRight

K{J} >> ArrowLeft
K{L} >> ArrowRight

[ristomatti]

@houmain Both examples work like a charm on my setup. I can't even notice a tiny lag that was previously associated with using an alpha key as a modifier which is crazy. Am I imagining this (= have I had too much to drink today) or have you discovered some clever new optimization? 😁

I've been around long enough to sense a chance of regression when a change feels almost too good. Hopefully that is not the case though! 🤞

[drivermix]

I just pushed a version 4.12.1, which fixes key repeats also in configurations like:

L{J} >> ArrowLeft
J{L} >> ArrowRight

K{J} >> ArrowLeft
K{L} >> ArrowRight

@houmain The new version fixes the original issues. Thank you!

Well, I don't mean to be a pest but it appears that I've encountered yet another strange scenario, and I swear I'm not making these examples up. :)

In this example, only the first shortcut repeat fine.

(F K){J} >>
F{K} >>

If I switch them like this...

F{K} >>
(F K){J} >>

now F{K} repeats when triggered, but when I try to hit (F K){J}.... F{K} kicks in before I can hit the J key. Once the J key is finally depressed, the (F K){J} statement starts repeating as expected. I mean, I realize that there's an issue of precedence here. So, is it even possible to resolve this? Perhaps there a way to script it differently, or would it require another update to make it work? Once again, I greatly appreciate your dedication and effort to answer questions.

[drivermix]

This might have unexpected side effects, but based on quick testing I was able to get back-and-forth movement with this config:

[modifier = "K"]
  J >> ArrowLeft
  L >> ArrowRight

[default]
  K{!100ms} >> K
  K         >>

@ristomatti Your example is a little over my head. :) Thanks for weighing in! I constantly learn more about keymapper from the examples people provide.

[ristomatti]

Well, I don't mean to be a pest but it appears that I've encountered yet another strange scenario, and I swear I'm not making these examples up. :)

Don't worry, you're definitely not the first one with these types of requests. 🙂

In this example, only the first shortcut repeat fine.

(F K){J} >>
F{K} >>

If I switch them like this...

F{K} >>
(F K){J} >>

now F{K} repeats when triggered, but when I try to hit (F K){J}.... F{K} kicks in before I can hit the J key. Once the J key is finally depressed, the (F K){J} statement starts repeating as expected. I mean, I realize that there's an issue of precedence here. So, is it even possible to resolve this?

If you stop to think about the mappings for a moment, you will likely understand why it doesn't work and why it's likely impossible to achieve exactly as you'd like. In the first example, the (F K) will stop to wait if J will be pressed, so the second mapping will never trigger. In the second example F{K} will trigger immediately and therefore the next mapping can not trigger.

If you're willing to except some mental/finger gymnastics, you can get close by making the first held down key different for each mapping and avoiding the (X Y) syntax (which will stop the processing and wait for the rest of the sequence regardless of which key you press down first):

F{K{J}} >> ArrowDown
K{F}    >> ArrowUp

Or alternatively you can make the first line a "might match" mapping, in which partial match does not stop processing the following mappings which kind of works in this particular case, but is likely not practical:

? (F K){J} >> ArrowDown
F{K}       >> ArrowUp

Based on my quick testing F{K} now sends ArrowUp. The mapping (F K){J} will trigger when you press down J, but so will the next mapping. In my testing this resulted in both ArrowUp and ArrowDown to be pressed at the same time, but it was quite sensitive to timing as you'll need to get the ArrowDown to be pressed first in order for it to repeat. The OS will then just ignore ArrowUp as only one key can repeat at the same time. At least this is my interpretation of what ended up happening.

I hope this made some sense. I'm too tired to double check what I wrote. 😄