Does tmux swallow extended keys?

[drowning-cat]

Issue description

tmux-extkeys.mp4

---

I also found that with extended keys enabled, is indistinguishable from in neovim.
See https://github.com/orgs/tmux/discussions/4398#discussioncomment-12607784

Required information

• tmux next-3.6, built from the master branch
• Linux, Arch Btw
• alacritty, kitty, ghostty, gnome-terminal
• tmux-256color

Logs:

• tmux-client-227540.log
• tmux-out-227542.log
• tmux-server-227542.log

[drowning-cat]

Keymaps weren’t working in Neovim (where I discovered the issue), but they are working now. I guess one of the Neovim updates solved the issue.

However, I still don’t understand why cat -v shows incorrect different key sequences.

[drowning-cat]

I feel that cat -v should print the same key sequences in <Terminal> + tmux and in the <Terminal> alone.
Or am I wrong?

[nicm]

I think C-S-h should be ^[[72;6u not ^[[72;5u. That's what xterm sends.

[ThomasDickey]

sure - a "1" would be a default/no-op. Per source:

                    Code     Modifiers
                  ---------+---------------------------
                     2     | Shift
                     3     | Alt
                     4     | Shift + Alt
                     5     | Control
                     6     | Shift + Control
                     7     | Alt + Control
                     8     | Shift + Alt + Control
                     9     | Meta
                     10    | Meta + Shift
                     11    | Meta + Alt
                     12    | Meta + Alt + Shift
                     13    | Meta + Ctrl
                     14    | Meta + Ctrl + Shift
                     15    | Meta + Ctrl + Alt
                     16    | Meta + Ctrl + Alt + Shift
                  ---------+---------------------------

[drowning-cat]

To be honest, I simply copied the key sequences from cat -v in Kitty (xterm-kitty) into the Alacritty config, but the behavior is the same with either ^[[72;6u or ^[[72;5u, at least for now.

---

I also found that with extended keys enabled, <C-i> is indistinguishable from <Tab> in neovim.

set -g extended-keys always

local counter = 0

vim.keymap.set('n', '<C-i>', function()
  counter = counter + 1
  vim.print(counter)
end)

vim.keymap.set('n', '<Tab>', function()
  counter = counter - 1
  vim.print(counter)
end)

[nicm]

I checked xterm and C-i and Tab are the same in mode 1, the application needs to request mode 2 for them to be different.

Similarly, in mode 2 C-h and C-S-h are different but in mode 1 they are the same.

So it seems like tmux is behaving correctly here (or xterm is also incorrect).

[drowning-cat]

From what you pointed out, I understand that tmux implements the xterm specification. An application must explicitly request the so-called mode 2 to allow extended keys.

• It is expected that cat -v prints non-extended key sequences.
• The <C-i>/<Tab> issue is most likely not tmux problem.

I'll keep the discussion open for a while in case someone wants to raise concerns, but it is formally closed.

Thanks for your response!