don't break unambiguous hotkey chain with other hotkeys

[rr-]

The man page reads:

It's also possible to bind a command to a sequence of keys: a-b-c show-text "command run after a, b, c have been pressed"

(This is not shown in the general command syntax.)

If a or a-b or b are already bound, this will run the first command that matches, and the multi-key command will never be called. Intermediate keys can be remapped to ignore in order to avoid this issue. The maximum number of (non-modifier) keys for combinations is currently 4.

Is it possible to lift the or b condition so that following:

p cycle pause
q quit
u-y-1 run some-command -y -s1
u-y-2 run some-command -y -s2
u-y-3 run some-command -y -s3
u-q-1 run some-command -q -s1
u-q-2 run some-command -q -s2
u-q-3 run some-command -q -s3

works despite u-q-* sharing its middle with q?

Currently pressing u followed by q will quit rather than running some-command, even though u makes it unambiguous. IMO it should be prioritized like this:

• Pressing p cycles pause
• Pressing q quits
• Pressing x does nothing
• Pressing u waits for input
• Pressing u-q waits for input rather than invoking quit
• Pressing u-q-1 runs some-command -q -s1
• Pressing u-q-p discards invalid binding chain and cycles pause
• Pressing u-q-q similarly quits
• Pressing u-q-x does nothing
• Pressing u-q-x-u has the same effect as pressing u
• Pressing u-q-u has the same effect as pressing u
• Pressing u-p discards invalid binding chain and cycles pause
• Pressing u-g similarly quits
• Pressing u-x does nothing
• Pressing u-x-u has the same effect as pressing u
• Pressing u-u has the same effect as pressing u

IDK how it fits into mpv architecture but this kind of behavior is usually implemented with finite state automata which are basically directed graphs where each edge consumes one input key, and node is (or isn't) tied to given command. Then the user input is passed through such graph, and the application maintains list of states the current input is in (it provides info if the binding is ambiguous for free, too).

[ghost]

It's all in input.c. Feel free to try it. I'm not going to bother because the input logic is already complex enough.