Strange stage behaviour. Keymaps in stage cancel held key
miroshQa opened this issue · 6 comments
My configuration:
CapsLock >> Escape
AltLeft >> Control
[stage]
Control{J} >> ArrowDown
Control{K} >> ArrowUp
Control{H} >> ArrowLeft
Control{L} >> ArrowRight
I use left alt instead control and control + j/h/k/l (alt + j/h/k/l physically) as arrow keys
The problem
In my text editor, I can select the next auto completion item using (down arrow key or ctrl + n) and the previous element using (up arrow key or ctrl + p)
Also I can scroll through the documentation of the autocompletion element using ctrl + u and ctrl + d
On the video below you can see it. I use ctrl + n / ctrl + p to select next / previous auto completion item and ctrl + d / ctrl + u to scroll the documentation
https://drive.google.com/file/d/11e8j6dwbIP_8yuxADBRKOwGa3mofeDZO/view?usp=drive_link
But my preferred way is to use the arrows that I have binded to ctrl + j/k (physically alt + j/k) instead of ctrl + n and ctrl + p
But when I do that something goes wrong
https://drive.google.com/file/d/1IZSQOCljILcvfZOBJfRlH4hnTNnI0ZST/view?usp=drive_link
I can select next / previous auto completion item using arrow keys (alt + j/k physically), but when after that I try to scroll documentation using ctrl + d it just print "d" as if the control (alt physically) hold has been canceled
How can I fix that?
It does not make a difference whether you are using a [stage] or not, right? (beside that you can only trigger this problem with Control and not also with AltLeft)
If you want to use not defined Control shortcuts, you have to define that Control should never be only an "optional prefix". Otherwise, when matching e.g. Control{J} >> ArrowDown, it is not reapplied when pressing D while Control is still held.
This is done by forwarding Control alone. But then you also have to define, that you do not want it to be still held in your mappings:
CapsLock >> Escape
AltLeft >> Control
[stage]
Control >> Control
Control{J} >> !Control ArrowDown
Control{K} >> !Control ArrowUp
Control{H} >> !Control ArrowLeft
Control{L} >> !Control ArrowRight
This got me thinking, whether it is possible to make keymapper less "expert friendly". Like forwarding the the common modifiers automatically (and adding a directive to prevent that).
This got me thinking, whether it is possible to make keymapper less "expert friendly". Like forwarding the the common modifiers automatically (and adding a directive to prevent that).
Are modifiers handled differently than other keys when it comes to forwarding? I'm asking as the example config only suggest immediately forwarding modifier keys but not the others.
My assumption is they aren't, but they just stop being forwarded after the modifiers are used as inputs in the config. And perhaps more specifically only if they are configured as the first charater to be pressed in a mapping? If my assumption is correct, wouldn't the same then apply to every other key also?
Thanks! This configuration solves the issue for me!
Are modifiers handled differently than other keys when it comes to forwarding?
No, the modifiers (Shift, Control, ...) are not handled differently.
I'm asking as the example config only suggest immediately forwarding modifier keys but not the others.
Do you mean why I did not also suggest to add J >> J. I think because it is not being used as modifier, neither in his configuration nor in typical applications.
My assumption is they aren't, but they just stop being forwarded after the modifiers are used as inputs in the config. And perhaps more specifically only if they are configured as the first charater to be pressed in a mapping? If my assumption is correct, wouldn't the same then apply to every other key also?
Keys are forwarded automatically when they did not match any mapping. The position in the input expression does not matter. Sorry, I can not completely follow you.
I am thinking about implicitly prepending the suggested mappings:
Shift >> Shift
Control >> Control
AltLeft >> AltLeft
with an automatic omission, when someone wants to map e.g. AltLeft to Control.
And then maybe even implicitly inserting the !Control of:
Control{J} >> !Control ArrowDown
Then the OPs initial configuration would have worked.
Do you mean why I did not also suggest to add
J >> J. I think because it is not being used as modifier, neither in his configuration nor in typical applications.
Sorry for not clarifying, I was referring to https://github.com/houmain/keymapper/blob/main/keymapper.conf.
Keys are forwarded automatically when they did not match any mapping. The position in the input expression does not matter.
This clarified things, thanks!
I am thinking about implicitly prepending the suggested mappings:
Shift >> Shift Control >> Control AltLeft >> AltLeft
I believe this could very well be a good idea. This also comes down to what I was trying to say. Why exactly these keys but not AltRight or Meta? I have noticed these particular keys coming up often in the reported issues, but I wonder if it could actually make things more confusing for others.
As an example, a remap that comes up often enough (at least within QMK/ZMK/TMK forums) is home row mods. Let's imagine someone who decides to first experiments with remapping the traditional modifiers, but has the end goal of setting up something like "home row mods". It could be quite confusing to find out the same approach that worked on the first remaps doesn't work anymore?
And then maybe even implicitly inserting the !Control of:
Control{J} >> !Control ArrowDown
I agree that the current default behavior was one of the things that took a good while to realise. But after realising what's going on, it made a lot of sense. It was just unexpected when thinking about it similarly as configuring keybindings within an app.
Why exactly these keys but not AltRight or Meta?
Good point. These would also have to be included.
It could be quite confusing to find out the same approach that worked on the first remaps doesn't work anymore?
Yeah, making it less confusing for everyone would likely be harder to document than to implement.
Maybe I will experiment with these ideas some day.