palettero plugin breaks `\u001b[` keybindings

[injust]

Description of the problem or steps to reproduce

1. Run palettero using its keybinding
2. Either run a command or cancel (Esc, Ctrl-Q, etc.)
3. Try to use a \u001b[ keybinding

For me, I have \u001b[1;9A (⌘-Up) bound to CursorStart and \u001b[96;5u (Ctrl-backtick) bound to CommandMode. After these steps, they both perform their default actions (⌘-Up moves the cursor one line up and Ctrl-backtick writes 96;5u in the editor.

Specifications

Commit hash: 68d88b57
OS: macOS Sonoma 14.5
Terminal: Ghostty

[dmaluka]

Looks like I can reproduce it, and looks like I already know what's going on: the problem is that if the same key is bound to some action as a normal ("human-readable") keybinding, e.g. Up, and to some other action as a corresponding raw keybinding, e.g. \u001b[A, micro doesn't detect that it is the same key, so the behavior is non-deterministic: it is undefined which of the two actions will be executed when we press the Up key: the one bound to Up or the one bound to \u001b[A.

And in this case palettero somehow triggers the change of behavior: before running palettero micro executes the action bound to the raw keybinding, and after running palettero it executes the action bound to the normal keybinding. I haven't found out why does palettero trigger this change, but that might be not so important. The behavior is inherently undefined anyway.

And a simple workaround for you would be just not to use a raw keybinding, use the normal keybinding instead. Indeed, why do you need to use a raw binding if a normal human-readable binding is available?

After these steps, they both perform their default actions (⌘-Up moves the cursor one line up [...]

I never used MacOS, but as far as I can see from the code, this action is bound to Up by default:

var bufdefaults = map[string]string{
	"Up":             "CursorUp",

So is ⌘-Up the same thing as Up?

Anyway, looks like you can just bind Up (instead of \u001b[1;9A) to CursorStart and it will solve the problem for you?

[injust]

Looks like I can reproduce it, and looks like I already know what's going on: the problem is that if the same key is bound to some action as a normal ("human-readable") keybinding, e.g. Up, and to some other action as a corresponding raw keybinding, e.g. \u001b[A, micro doesn't detect that it is the same key, so the behavior is non-deterministic: it is undefined which of the two actions will be executed when we press the Up key: the one bound to Up or the one bound to \u001b[A.

And in this case palettero somehow triggers the change of behavior: before running palettero micro executes the action bound to the raw keybinding, and after running palettero it executes the action bound to the normal keybinding. I haven't found out why does palettero trigger this change, but that might be not so important. The behavior is inherently undefined anyway.

And a simple workaround for you would be just not to use a raw keybinding, use the normal keybinding instead. Indeed, why do you need to use a raw binding if a normal human-readable binding is available?

Anyway, looks like you can just bind Up (instead of \u001b[1;9A) to CursorStart and it will solve the problem for you?

I am trying to bind ⌘-Up, which is \x1b[1;9A. There is no human-readable equivalent for that. This has nothing to do with Up, so I'm confused why you mentioned it.

[injust]

I think this is the real problem.

Before running palettero, ⌘-Up and ⌥-Up in raw gives me:

EventRaw:  [1;9A: "\x1b[1;9A"
EventKey: Alt-Up: "\x1b[1;3A"

After running palettero, I get this instead:

EventKey: Alt-Up: "\x1b[1;9A"
EventKey: Alt-Up: "\x1b[1;3A"

[injust]

Another example: Before running palettero, control-backtick gives me:

EventRaw:  [96;5u: "\x1b[96;5u"

After running palettero, I get this instead:

EventKey: Alt-[: "\x1b["
EventKey: 9: "9"
EventKey: 6: "6"
EventKey: ;: ";"
EventKey: 5: "5"
EventKey: u: "u"

[dmaluka]

I am trying to bind ⌘-Up, which is \x1b[1;9A. There is no human-readable equivalent for that. This has nothing to do with Up, so I'm confused why you mentioned it.

You said that ⌘-Up moves the cursor one line up by default, so I assumed that means that ⌘-Up is bound to CursorUp by default, which would mean that ⌘-Up works the same way as Up.

Anyway, nevermind. Looks like I've found the actual root cause. It should be fixed by #3468.