Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
tuftman-0 opened this issue Jan 25, 2025 · 1 comment
Labels

Comments

@tuftman-0
Copy link

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

@tuftman-0 tuftman-0 added the bug label Jan 25, 2025
@Screwtapello
Copy link
Contributor

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>).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants