Overload for some keyd only

[tobiasBora]

I just fall in love with mod keys (e.g. using a + u instead of backspace)… so much that I try to use them so quickly that keyd cannot anymore distinguish whether I want to actually type au or if I want to delete the last character (of course, it has no way to know, since I don't pause for at least 200ms as expected). But I realized that I would never type g followed by u (this is because in bépo, g is actually producing a comma, and comma are basically never directly followed by letters), so g would be a perfect candidate for a modkey!

So basically, I'd like:

• if g is typed reasonably quickly, it just prints g
• if g is typed but hold alone during a long time, it prints nothing (I often do that when I realize that I did not want to move/delete something)
• if g is pressed in combinaison with u, it types backspace
• otherwise, if g is pressed in combinaison with a different, non-arrow/… letter (typically rolling), it prints g followed by this letter.

My tries

Sadly, I can't find how to implement this. For instance, if I do:

g = overload(arrows, g)

then rolling ga for instance will only print a instead of ga. It is maybe not the cleanest solution, but I think this would be possible if we provide a chord-like feature like:

[main]
g = overloadt(arrowsfromg, g, 200)
g(200)>u=backspace
[arrowsfromg]
u=backspace
a = macro(g a)
b = macro(g b)
…
# do the same for all keys… not the cleanest but discussed in https://github.com/rvaiya/keyd/issues/756

where the semantic of g(200)>u would be to fire the action if u was pressed after g within 200ms.

[rvaiya]

where the semantic of g(200)>u would be to fire the action if u was pressed after g within 200ms.

This is already how chording works.

I believe what you want is:

g = overloadt(arrows, g, 200)
g+u = backspace

[tobiasBora]

Thanks for your answer.

This is already how chording works.

Do you mean that the semantic of g+u is not the same as the semantic of u+g? Cause if u is pressed first I don't want to trigger backspace as pressing a letter right before a comma is fairly common.

I also tried this before, but a second problem is that chord are triggered by default only if I press them within 50ms (and I don't want to change this value since I use chords elsewhere where 200ms would be too high). So if I press these keys before 50ms or after 200ms this works, but if I press them within 100ms it will type gu instead of backspace.

[rvaiya]

Do you mean that the semantic of g+u is not the same as the semantic of u+g? Cause if u is pressed first I don't want to trigger backspace as pressing a letter right before a comma is fairly common.

Sorry, they are indeed equivalent. I didn't realize you wanted this kind of asymmetry.

The idea of a chord is that both keys should be struck 'simultaneously' (the gap between their depression is not perceptible to a human). Your chording interval should be sufficiently low (default is 50ms) that anything other than what you pereceive as pressing both keys together is not interpreted as a chord.

Can you elaborate on your use case? If your goal is to deliberately strike g+u as a chord, then you are unlikely to be able to distinguish between u+g and g+u. Is there some precedent for what you are trying to achieve? (e.g implemented in QMK).

[tobiasBora]

The idea of a chord is that both keys should be struck 'simultaneously'

Sure, that's why I don't think chords is the right tool to use here (together with the symmetry), as in my case the range is rather 50-200ms and is definitely too slow for a chord. That's why I suggested a different syntax above, that could fit my use case, maybe not very elegantly but at least with minor modifications to keyd (hopefully). But other solutions might work as well.

Can you elaborate on your use case?

Well, I just want to have a modkey that I can use directly to delete a character without waiting 200ms when pressing g followed by u, and that behaves like a normal keyboard when used with a key that is not bound to an action, like g followed by space or e… (for the exact details of how I expect this to behave, see my first post). I don't have a QMK keyboard to test QMK's implementation of this so it is hard to tell if they already implement this.