group output error

[kbilsted]

hi

there are problems when using two group definitions

i have remapped all my keys such that I am no longer using qwerty and as the first i define

(N I O ) >> F O U N D   
(A S D) >> I O N  

when both definitions are in use it triggers the error..

the error happens when pressing eg s d fast which produce id..

without the above defs it produces in (which is correct according to other definitions).

[ristomatti]

You might want to give more examples. At least I'm not sure if I understand what is the expected result. I would expect pressing s d to output sd with the snippet of config you've given, which would make it a bug if it results in id. But I got lost when you say s d should result in in?

Doesn't (A S D) >> I O N mean when you press A S D all at the same time, it should produce the output ion and pressing any two key combination from the keys A S D should result in the the output they'd normally do?

which is correct according to other definitions

What are the other definitions?

[kbilsted]

@ristomatti the other defs are simple remaps

I >> U
O >> O
S >> I
D >> N
... 

you are correct in your observation that the group should not be triggered

[ristomatti]

I'll try if I can reproduce it. So the full config to would be this?

I >> U
O >> O
S >> I
D >> N

(N I O ) >> F O U N D   
(A S D) >> I O N 

[ristomatti]

At least with that, I can't get reproduce the output of id:

inininininininininininniniininin
inininininininininininniniininin
ininininininininin

Out of curiosity I tried the (A S D) combination:

ionionionnioinonioion
ionionionnioinonioion

And the (N I O):

foundofundfounduofnd
               ^^^^^
foundfoundfounduofndfounduofnduofndufond
               ^^^^^     ^^^^^^^^^^^^^^^

I then tried it again with some more thought. I can consistently make nio output found if I press the keys down in that order, e.g N{I{O}} but if I press them the other way round O{I{N}} the output ends up being oufnd every time. I get another "mispelling" if I try to press I down first.

asd behaves the same way. The defined output comes in the correct order only if the keys get pressed like A{S{D}}. Intresting! I can only imagine what you're trying to make out of this or is it just testing if Keymapper can do it or not? 😄

[ristomatti]

I tried changing the last lines to this:

(N I O ) >> 'found'   
(A S D) >> 'ion'

...but still get the same behavior.

BTW, why do you map O >>> O? If I comment it out, I get found as a result from either N{I{O}} and O{I{N}} but if I try to press them all at once (the sequence the keys get registered is more random), I occasionally get the output in mixed order.

[kbilsted]

thanks for testing. no all keys are remmapped.. i found the bug because i kept "misspelling" and it made no sense..

my presses are normal rolling.. ie holding s down while pressing d

[kbilsted]

try

(N I O ) >> F O U N D   
(A S D) >> I O N  
I >> U
A >> S 
S >> I
D >> N
N >> F

also found out if i press and hold d and press s (rolling the oher way) i get ns

[kbilsted]

version 4.1.1

[ristomatti]

The combined keys seem to work pretty much flawlessly when defined first. But I can reproduce what you described both ways.

• hold S then press D, output is in
• hold D then press S, ouput is ni
• roll from S to D, ouput is id
• roll from D to S, ouput is ns

(tested on version 4.1.2)

[ristomatti]

I believe getting this right in all use cases might be really difficult.

In addition to that issue, there's the compromise with the key combinations. If defined afterwards, the output can get mixed up and if defined first, you lose key repeat of any of the keys used in the combination (which to be fare, is to be expected).

[ristomatti]

I find the idea of using Keymapper to define an alternative layout somewhat difficult to grasp/maintain on the config side. If I think about it intuitively, you'd first define to what key each singular key maps to. Then when adding further mappings, you would do it based on the mapping defined earlier, but it doesn't work like as each key press in interpreted by the key code, right?

So if I'd do e.g. a dvorak/workman layout for the alphas, then swap the keycaps accordingly, I would still need to do the following mappings using the original key names (= keycodes sent by the keyboard).

Unless I've got this completely wrong, I'd think to make the process more intuitive, the key handling would need to be done in two phases based on two separate config files. First would define the singular key remaps, and the second would work the same way as it works now, with the exception that the mappings could be defined based on remaps done in the first phase.

[kbilsted]

@ristomatti Possibly other tools are more suited, but eg kanata has a hard time with using ALT as a layer swap key while at the same time allows the alt-tab, or the alt+mouse = column select so I tried Keymapper and this is where I am at. If you can advice on kmonad or kanata setup ill gladly try remapping using those.

I don't swap any key caps I learn the keyboard by heart and sometime use my always-on-keyboard display ;)

One could do multiple configurations as you suggest, but perhaps we are bending the tool to where it doesn't want to be. In any case my complaints were about unmatched groups having effect on the output, not changing the whole configuration language

[kbilsted]

@ristomatti when the layout has matured more I'll gladly share it with others. It's awesome so far.. I just need to get to 50 WPM before I can judge if it is insanity or ingenious what I'm doing! drop me an email for private further conversations rollercoasterlayout@gmail.com

[ristomatti]

I haven't used either kmonad or kanata. I did check the various alternatives but either the configuration looked tedious or missed some feature I wanted. I might have installed some of them and then immediately uninstalled due to bugs or other reasons.

Keymapper looked like the one I was looking for, even to the point I went through the hurdle of figuring out how to build it on Ubuntu 20.04 which is not supported. It was well worth the effort and my search is over. 🙂

[houmain]

Thanks for helping with the reproduction. This should be fixed in the 4.1.3 release. I mean it should no longer forward keys unmapped when it can no longer match the group.

the key handling would need to be done in two phases based on two separate config files.

I have also thought about that once and might implement it some day.

[ristomatti]

@houmain In case you're not aware of this, GitHub can automatically link commits to issues. This gives instant feedback to people watching an issue.

For example, in the release notes for 4.1.3 you mention this issue has been fixed. By using specific keywords in your commit messages, the commits can be linked to the related issues. In this case, if the commit message of 81312c7 would have contained the magic words "fixes #138", the commit would be shown on this issue therad.

There's plenty of alternative phrases to use: https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword.

It's a bit unclear to me though if a pull request needs to be made for this to occur if it's enough to just commit on the main branch.

Edit: @houmain was faster, so removed a comment mentioning the release.

[ristomatti]

I have also thought about that once and might implement it some day.

Somehow I'm not surprised. 😄

I'll test the fix out of curiosity.

@houmain Did you notice #139? It needs to be updated to include --set-config though. I'm happy to see --no-notify as well. I use Rofication for noticationsand it only shows how many unread notifications I have. To see the notifications, Rofication needs to be manually opened. This is great for not getting distracted from notifications in general, but when I'm actively testing some new mappings, I might miss other notifications, thinking it's just from saving the config.

Does it also silence the notification of an invalid config though?

[ristomatti]

I can no longer reproduce either issue when config is defined like this:

(N I O ) >> F O U N D   
(A S D)  >> I O N  

I >> U
A >> S 
S >> I
D >> N
N >> F

If I move the two first lines in the end, the output is not consistent:

• pressing asd by rolling the keys in that order results in sin
• pressing dsa the same way results in nis
• pressing nio the same way results in fuond
• pressing oin the same way results in found

I don't know if this is to be expected.

[kbilsted]

Lol who knows ;)

[ristomatti]

I did a little experiment to attempt fixing key repeat. While doing it, I noticed a bug, but also got some interesting results to mess up with our brains.

This is the config:

I !100ms I >> U U
A !100ms A >> S S 
S !100ms S >> I I
D !100ms D >> N N
N !100ms N >> F F

(N I O) >> F O U N D   
(A S D) >> I O N  

I >> U
A >> S 
S >> I
D >> N
N >> F

With this config, the individual key remaps seem to work as expected and so does my key repeat fix attempt. But the grouped keys give a rather interesting outcome 😬:

Pressing oin in a rolling manner results in found as one would expect, but doing it the other way (ion) results in fuond (the same output as I got from nio described on my previous comment).

With the (A S D) things get interesting.

Rolling asd outputs sion while rolling dsa results in nion. 🤔

[ristomatti]

I did a further experiment, changing the combined keys in the above config to:

N{I{O}} >> F O U N D
A{S{D}} >> I O N

This obviously breaks pressing them at the same time or in a reverse order. When typed in the specified order, the output is exactly the same as described above.

When pressed the same time in this sequence: asd -> fuond. And as previously nio -> sion. It would be interesting to know how the internal processing ends up with the extra character.

[ristomatti]

Given the amount of things occurring at the same time, I would almost be ready to just accept this to be "unfixable" and call it a day. What do you think @houmain, is it just a bug waiting to be fixed or does this involve some OS/hardware level randomness that just appears in a different place when one issue is fixed?

[houmain]

is it just a bug waiting to be fixed or does this involve some OS/hardware level randomness that just appears in a different place when one issue is fixed?

I tried these configurations a bit. The results may not be what the creator intended, but I don't think they are illogical.
For example, with this configuration:

I >> U
A >> S 
S >> I
D >> N
N >> F

(N I O ) >> F O U N D   
(A S D)  >> I O N  

rolling over N I O results in fuond,
rolling over I N O results in ufond,
rolling over O I N and O N I result in found.

The first two immediately output something as soon as they are pressed (F and U in the corresponding order).
The last two wait after the O, whether more keys of the group follow.
In the first two cases, when the group is completed only O N D need to be pressed, since F and U are already down.

[houmain]

Does it also silence the notification of an invalid config though?

Yes, --no-notify silences all notifications.

[ristomatti]

Perhaps consider a flag that only silences success notifications? I still enabled the flag though. Most of the times when I edit the mappings, I have my ContextActive debug log visible. If I see nothing logged after saving, I know I messed up and I'll need to run keymapper --check. 🙂

Normally just an undo would be sufficient, but I've recently changed Helix to be my default text editor. As much as I've liked it so far, it's way of selecting text by default on each movement or when jumping through search matches still gets me off guard. I often end up unknowingly editing multiple lines at the same time, some of which might be hundreds of lines off screen. 😁

[kbilsted]

@houmain are you interested in working on supporting "adaptive keys" as describe above ?

[houmain]

Yes, I think I could implement something like #137 (comment) and then I could also add a way to access the recently typed keys.

[ristomatti]

The results may not be what the creator intended, but I don't think they are illogical.

Now it does make sense indeed, thanks for the step by step explanation. Luckily I'm not interested in trying to implement anything as exotic (at least for now) as my brain would melt debugging issues like this. 😅

Accessing the runtime value of Any or aliased keys would be great for debugging as well if it would mean the pressed key could be used on the output side e.g. to log it within an executed script.

[kbilsted]

you may be right.

[ristomatti]

@kbilsted Was the reply for me or @houmain and to what comment?

[houmain]

A few new features are available in the 4.3.0 release.

The results may not be what the creator intended, but I don't think they are illogical.

!Any allows to release already pressed keys before outputting the new ones. Which should make the result less surprising:

I >> U
A >> S 
S >> I
D >> N
N >> F

(N I O ) >> !Any F O U N D   
(A S D)  >> !Any I O N  

rolling over N I O results in fufound.

Yes, I think I could implement something like #137 (comment)

One can write now:

? C A T >> Backspace Backspace D O G

The mapping is skipped as long as it does not match completely. So it does not wait after the C whether a A follows...

[ristomatti]

I'll leave the honor of testing this first to you @kbilsted. 😁

I haven't yet done any testing myself but I believe both additions sound great! The ? prefix could help with some issues I've ran across earlier on (I just don't remember which one at this point).

Support for !Any on the output will definitely be useful as it should make a lot of boilerplate in my existing config unnecessary. For example to simplify these (or allow replacing with "inline" !Any AltLeft etc.):

_Meta           = !ControlLeft !ControlRight           !MetaRight !AltLeft !AltGr MetaLeft
_MetaRight      = !ControlLeft !ControlRight !MetaLeft            !AltLeft !AltGr MetaRight
_Alt            = !ControlLeft !ControlRight !MetaLeft !MetaRight          !AltGr AltLeft
_AltGr          = !ControlLeft !ControlRight !MetaLeft !MetaRight !AltLeft        AltGr
_Control        =              !ControlRight !MetaLeft !MetaRight !AltLeft !AltGr ControlLeft
_ControlRight   = !ControlLeft               !MetaLeft !MetaRight !AltLeft !AltGr ControlRight
_Shift          = !ControlLeft !ControlRight !MetaLeft !MetaRight !AltLeft !AltGr ShiftLeft
_ShiftRight     = !ControlLeft !ControlRight !MetaLeft !MetaRight !AltLeft !AltGr ShiftRight

It should also remove the coupling with input keymaps and abstracted output mappings. For instance, in many cases I've had to use one of the above on some of the abstracted commands when the the input part uses a different modifier. The most common scenario has been mappings that have Escape{X} or AltGr{X} as input and AltLeft{Y} or ControlLeft{Y} on the output. Some apps interpret the result as something like (AltRight AltLeft){Y}, ignoring the action I've intended to trigger.

With !Any, there'd still be coupling but something that needs to be handled case by case. In most cases in my config I want exactly the output I specify. I migtht end up with something like _ = !Any and use that for all abtracted commands to make it less verbose. In some cases I've used ^ X{Y} on the output but it's not always ideal.