Macro Repetitions

[flynx]

Hi

The keys remapped to a macro( .. ) are triggered once per press and do not get repeated as normal keys when the key sequence is held down.

To reproduce:

leftshift = macro(xx)

Pressing and holding leftshift will print "xx" only once and will never repeat.

Expected behavior:

Repeating is expected by default.

In case of macros (IMHO) repeating the whole macro would be logical, also by default.

Would be nice to be able to control in config:

• toggle repeating for a key,
• for macros set key sequence (or sequences) to be repeated.

Thanks for a great piece of software!

---

P.S. I'm not suggesting a specific syntax here as I both do not have the feel for it yet and I did not dive into the implementation (yet)...

[rvaiya]

Normal keys don't actually get repeated, they just don't generate a key up event until they are released. This gets interpreted higher up the input stack as 'multiple keypresses'. Macros by contrast consist of multiple key sequences which have no notion of being 'held down'

E.G

macro(C-t hello world enter) necessarily releases C-t before typing 'hello world'.

Baked into the definition of a macro is a set of key releases.

As you noted, it is possible to treat these as logical units by synthetically generating 'repeat events' which repeat all key up/down pairs for a second time, but this increases complexity and can produce unintuitive results (e.g accidental multikey actuations, chained timeouts, etc).

In practice I am not convinced that macros need to be repeated often enough (when an additional deliberate actuation makes sense) to warrant making them repeatable in this way.

Can you provide an example of when this would be useful?

[flynx]

Not yet sure that my code is the right way to go for the specific task, hut here it is:

The idea is to move windows on the desktop (Gnome in this case) with one hand without finger acrobatics (laptop keyboard)...

rightalt = overload(rightalt, rightalt)

# ...

[rightalt:A]
# Gnome: move window...
left = macro(A-f7 20ms left left enter)
right = macro(A-f7 20ms right right enter)
up = macro(A-f7 20ms up up enter)
down = macro(A-f7 20ms down down enter)

This is a functional port of my AutoHotKey setup on windows, but the windows version is cleaner as it's directly moving windows rather than sending keys...

This specific task aside, macro repeat would be useful for things like escape sequence mappings, control key sequences and the like.

---

P.S. while writing this I've thought of a different hacky workaround that would enable repeat: simply use a set of "virtual" keys not present on the keyboard and map them in Gnome, but this seems even less clean than the above... -- nope, wont work as there is no direct way to move a window in a specific direction in Gnome, at least not on the surface...

P.P.S. I see what you mean about repeats (level), I originally thought that keyd was filtering keys after the repeat is handled, thus this is simply an issue of re-handling the incoming repeated keys... but at this level... things just got a bit more complicated =)

[rvaiya]

left = macro(A-f7 20ms left left enter)

Even if you could repeat this, it would probably not work as seamlessly as you expect. The 20ms timeout would apply to each repetition and there would be a lot of redundant 'move mode' activations. There would also have to be an additional timeout before the actual repeat events to stagger them properly and prevent accidental actuations.

Fundamentally you want to change the behaviour of the window manager so that <mod>-<key> immediately begins moving a window until <key> is released. Macros are the wrong tool for this job. Most window managers support this behaviour out of the box, so it is odd that Gnome forces a mode based approach upon the user. Having said that, I believe it should be possible to script it to do what you want.

[flynx]

Even if you could repeat this, it would probably not work as seamlessly as you expect. The 20ms timeout would apply to each repetition and there would be a lot of redundant 'move mode' activations. There would also have to be an additional timeout before the actual repeat events to stagger them properly and prevent accidental actuations.

Yes, that's exactly why the best default here would be the system repeat settings... though I'm not sure how fragmented this is in the Linux distro zoo =)

Fundamentally you want to change the behaviour of the window manager so that <mod>-<key> immediately begins moving a window until <key> is released. Macros are the wrong tool for this job. Most window managers support this behaviour out of the box, so it is odd that Gnome forces a mode based approach upon the user. Having said that, I believe it should be possible to script it to do what you want.

Yes indeed, this is definitely not the best way to solve this problem, it's a bit cringe-y to me to have to solve essentially a window-manager-level issue at the kernel level, but it's simple and it works, and since Gnome exposes only a begin-move action, the only correct way to get around this that I see, is writing a Gnome extension, which I might eventually do but not now =)

But we got a bit off track =)

IMHO, all keys (bindings/mappings) should behave consistently (POLS), in case of a key triggering a macro( .. ):

• I was surprised that they were not repeating (I do get why now though),
• there is no mention of key repeat in the docs.

On the interface level, i.e. "a user presses a physical key" a key bound to a macro is not (should not be) different to any other key thus it would be quite logical to expect it to behave as any other key press.

General use cases that I see for this (my hack aside) are:

• gaming macros
• terminal macros (involving escape sequences, like switching colors, modes, special chars, etc.)

[rvaiya]

I see, is writing a Gnome extension, which I might eventually do but not now =)

This is indeed the correct approach (in conjunction with bugging upstream for sane defaults ;)).

IMHO, all keys (bindings/mappings) should behave consistently (POLS), in case of a key triggering a macro( .. ):

On the interface level, i.e. "a user presses a physical key" a key bound to a macro is not (should not be) different to any other key thus it would be quite logical to expect it to behave as any other key press.

I am inclined to agree, the original implementation was conservative to avoid breaking things in combination. I also didn't
think many people would notice.

terminal macros (involving escape sequences, like switching colors, modes, special chars, etc.)

I hadn't considered this, though I would like to meet the person that uses it for this purpose :P.

You have persuaded me to make this the default behaviour, but I am currently in the process of cleaning up the config logic and making some design changes in preparation for version 2.0. I should get to this shortly after that has been released.

[flynx]

... though I would like to meet the person that uses it for this purpose :P.

Well..... I was speaking from experience but that was a couple of projects more than a decade back where I couldn't use anything fancy like curses/ncurses =)

[rvaiya]

This should be supported in the latest version. Sorry for the delay.

[rvaiya]

I'm closing this for now. Feel free to reopen it.