[QUESTION] does kakoune support modifyOtherKeys level 2?

[terminalzeiro]

Question

I trying to bind <c-s-w>, but kak reconize that as <c-w>.

• terminal that I'm using: xterm 379
• modifyOtherKeys=2
• formatOtherKeys=1 ("CSI u" for extended keys)

[krobelus]

On Sun, Jan 12, 2025 at 04:45:10PM -0800, terminalzeiro wrote: does kakoune support modifyOtherKeys level 2? I trying to bind <c-s-w>, but kak reconize that as <c-w>. terminal that I'm using: xterm

Not yet. It should be doable to add. I think we could change \033[>4;1m to \033[>4;2m and maybe add some key decoding logic to src/terminal_ui.cc. Unfortunately xterm doesn't send CSI u by default (see formatOtherKeys) but the default format might still be good enough. I wonder what should be the long-term plan. We're mixing modifyOtherKeys with the kitty keyboard protocol, which is both good and bad.

[Screwtapello]

Unfortunately xterm doesn't send CSI u by default (see formatOtherKeys)
but the default format might still be good enough.

It doesn't, but it's easy enough to change if a lot of apps use the Kitty protocol, and Kakoune learn to parse the xterm syntax in commit 2c923ba.

[terminalzeiro]

interesting info: tmux since 3.5 works with modifyOtherKeys level 2 and "CSI u" (new server option extended-keys-format).

[krobelus]

On Wed, Jan 15, 2025 at 01:04:22AM -0800, Screwtapello wrote: > Unfortunately xterm doesn't send CSI u by default (see formatOtherKeys) but the default format might still be good enough. It doesn't, but it's easy enough to change if a lot of apps use the Kitty protocol, and Kakoune learn to parse the xterm syntax in commit 2c923ba.

Yeah, it looks like this is irrelevant. As long as apps like Kakoune can parse the XTerm syntax, no user needs to waste their time fiddling with formatOtherKeys, (the two formats are equally expressive). @terminalzeiro below is a patch to make Kakoune use level 2 of modifyOtherKeys. One problem with this is that xterm sends keys like "<c-s-W>", which deviates from XKB behavior where the shift modifier is consumed, producing "<c-W>". Either syntax can probably still be mapped but "<c-s-W>" seems deprecated; it will not work on terminals that implement the kitty keyboard protocol. As a workaround, I added a change to consume the shift modifier after the fact, so we also get "<c-W>" in xterm. Removing the shift modifier needs knowledge of the keyboard layout -- for example how to know whether '/' is a shifted key or not. This is weird because Kakoune really shouldn't care about the keyboard layout (I assumed English here). Even taking a dependency on e.g. libxkbcommon would still be incorrect if inside SSH etc. We should fix terminals to send unambiguous keys; the kitty keyboard protocol is becoming the de-facto standard, see https://sw.kovidgoyal.net/kitty/keyboard-protocol/#why-xterm-s-modifyotherkeys-should-not-be-used Until then, feel free to use this patch :) diff --git a/src/terminal_ui.cc b/src/terminal_ui.cc index 672626e48b..0bb797beae 100644 --- a/src/terminal_ui.cc +++ b/src/terminal_ui.cc @@ -808,10 +808,18 @@ auto masked_key = [&](Codepoint key, Codepoint shifted_key = 0) { int mask = std::max(params[1][0] - 1, 0); Key::Modifiers modifiers = parse_mask(mask); - if (shifted_key != 0 and (modifiers & Key::Modifiers::Shift)) + if (modifiers & Key::Modifiers::Shift) { - modifiers &= ~Key::Modifiers::Shift; - key = shifted_key; + if (shifted_key != 0) + { + modifiers &= ~Key::Modifiers::Shift; + key = shifted_key; + } + else if (is_upper(key) + or contains("~!@#$%^&*()_+{}\"\\<>?", key)) + { + modifiers &= ~Key::Modifiers::Shift; + } } return Key{modifiers, key}; }; @@ -1487,7 +1495,7 @@ write(STDOUT_FILENO, "\033[?1049h" // enable alternative screen buffer "\033[?1004h" // enable focus notify - "\033[>4;1m" // request CSI u style key reporting + "\033[>4;2m" // request CSI u style key reporting "\033[>5u" // kitty progressive enhancement - report shifted key codes "\033[22t" // save the current window title "\033[?25l" // hide cursor