[BUG] execute-keys inconsistency when evaluating literal control characters

[tuftman-0]

Version of Kakoune

v2024.05.10

Reproducer

Ok this is a little confusing to write out because we're dealing with literally writing out things that would normally signify a key press.

to reproduce bug type these two expressions out in kakoune

1. :exec i<control r literal char># written like exec i then insert the <c-r> char by pressing <c-v><c-r> then adding # after
2. :exec i<c-r># when written char for char literally

these output different results

Outcome

output of first expression
-> writes # at each cursor

output of second expression
-> writes the index of the cursor at each cursor

Expectations

both expressions should write the index of each cursor at each cursor
the <c-r> literal character should be evaluated the same as literally typing out <c-r>

Additional information

I've already tried enclosing the expressions in quotes, it doesn't make a difference

[Screwtapello]

It looks like Kakoune only accepts control characters that map to non-modified keys, so \x1B becomes <esc>, not <c-[>:

kakoune/src/keys.cc

Lines 100 to 109 in 28a82b0

	switch (cp)
	{
	case '\n': return Key::Return;
	case '\r': return Key::Return;
	case '\b': return Key::Backspace;
	case '\t': return Key::Tab;
	case ' ': return Key::Space;
	case '\033': return Key::Escape;
	default: return cp;
	}

The syntax that execute-keys parses does not represent a byte-string, or even a string of Unicode codepoints, it represents a sequence of key-presses (with the caveat that printable characters are assumed to be "whichever key produces that character", to avoid getting stuck in the weeds of keyboard layouts). So even though ASCII happens to encode Control-R as \x12, execute-keys chooses to represent it as <c-r> for consistency with all the key-presses that ASCII doesn't encode, like <s-tab> and <a-n>.

I don't think this is a bug, as such. To avoid confusion in the future, it might be a good idea for execute-keys to throw an error if it gets unexpected control characters, just like it throws an error if it gets an unexpected modifier (<m-x>) or an unexpected function key (<f99>).

[mawww]

Could you expand on why you would need this ? Both behaviours look reasonable to me.

[tuftman-0]

Honestly it's for code golf challenges, typing character literals is fewer keystrokes than typing out the key representations. I totally understand why you wouldn't make this work especially since it's pretty niche and it's impossible for keys with the alt modifier anyways. Absolutely not a big deal, just fun nonsense.
edit:
Also macros are affected. I expected it to work that way because it works like that in vim with macros and because some other control character literals like escape work fine. But yeah, I understand that typing out key sequences literally in exec keys, or when editing macros is kinda niche.