Support macro-style keybindings

[the-mikedavis]

Macro key-sequences can be used to implement custom keybinds for commands that require some sort of input like t or mi:

[keys.normal]
D = "@t<ret>d"
W = "@miw"

To implement them, we parse a sequence of KeyEvents the same way that we parse macro input, then execute them by setting up a callback which passes the KeyEvents through the compositor.

Closes #1383

[Omnikar]

The issue of static commands being executed immediately while macros are executed by the compositor afterwards doesn't seem to be resolved?
For example, given

"D" = ["find_till_char", "@<ret>", "delete_selection"]

the expected behaviour upon pressing D would be deleting to the end of the line (specifically selecting to the end of the line and then deleting), but the actual behaviour is deleting the current selection, then selecting to the end of the line. This is because delete_selection runs before the <ret> key is processed.

[the-mikedavis]

Ah nice catch, thanks for the good example! That's a tricky case. It's partially related to #4013.

We may want to support macro keybinds initially by disallowing them in sequences: supporting macro keybinds is straightforward if we ignore sequences.

I'll push a change to fix that case (and #4013) but I feel like it might be a bit hacky: I'm adding a fake Event for the compositor to handle so that it can handle sequences that use callbacks in the correct order.

[archseer]

There's also #4244

[Omnikar]

So the expected behaviour is happening now, good 👍. However, one small bug I've found: take the D command example. When it's executed, we get the desired behaviour of deleting to the end of the line, but a phantom D is rendered in the bottom right corner until the next keypress.

[the-mikedavis]

There's also #4244

It looks like #4244 has a similar concept for pending commands. It fixes the problem for on-next-key callbacks but not the compositor callbacks used by macros (cx.callback).

a phantom D is rendered in the bottom right corner until the next keypress

Whoops, forgot to clear the pseudo-pending 😅. Should be fixed in the latest

[tmke8]

Maybe this isn't easily doable but wouldn't it be nicer if instead of

[keys.normal]
D = "@t<ret>d"
W = "@miw"

you could write

[keys.normal]
D = ["@find_next_char <ret>", "delete_selection"]
W = "@select_textobject_inner w"

(or with some symbol other than @) because that way there doesn't need to be an existing keymapping for find_next_char and select_textobject_inner? (And also the resulting config would be a bit more robust to other changes in your keymap.)

[the-mikedavis]

That style is also possible with this branch:

[keys.normal]
D = ["find_till_char", "@<ret>", "delete_selection"]
W = ["select_textobject_inner", "@w"]

[tmke8]

Do you still want to get this merged? I saw you marked it as draft.

[the-mikedavis]

There's a regression for long lists of regular commands where we don't re-render after executing the commands. The changes around that are a bit hacky anyway so I need to think about how to do this nicely (and without regressions)

[llakala]

Ah nice catch, thanks for the good example! That's a tricky case. It's partially related to #4013.

We may want to support macro keybinds initially by disallowing them in sequences: supporting macro keybinds is straightforward if we ignore sequences.

I'll push a change to fix that case (and #4013) but I feel like it might be a bit hacky: I'm adding a fake Event for the compositor to handle so that it can handle sequences that use callbacks in the correct order.

Running into this now. Any chance of a follow-up PR to get macro keybinds working in sequences?

[KiaraGrouwstra]

could we get a new release for this feature? 🙏

[the-mikedavis]

yeah the hope is to cut a new release either later this month or in early January as time allows

[ThinkChaos]

@llakala I made an issue for tracking: #12420 - Support macros in keybinding sequences