Setting exteKeys in tmux prints raw keys codes in neovim

[rbhanot4739]

Hello,

I am using tmux with ghostty and have set the set-option -g extended-keys always to ensure that the modifier keys like Shift and Ctrl are correctly recognised and work inside neovim.

This work fine where the neovim mappings for Shift and Ctrl work correctly however I am noticing a weird side effect of setting the ``set-option -g extended-keys always` that whenever I paste something inside neovim within a tmux session it prints raw keys codes along with it.

For example the below text

  cmdline = {
    enabled = false
  },

when pasted in neovim within tmux is rendered as

  cmdline = {�[27;5;106~    enabled = false�[27;5;106~  },

Doing quick check show that ghostty does not have support for extkeys and hence this issue seems little obvious.

❯ tmux display -p '#{client_termfeatures}'`
bpaste,ccolour,clipboard,cstyle,focus,title

So I was wondering if there is a way to fix this or is this support planned for future ?

[claytonchew]

has anyone found a workaround for this?

[00-kat]

What is extended-keys? Ghostty supports both Fixterms and the Kitty keyboard protocol, the latter of which Tmux doesn't support. I had thought extended-keys is the former, Fixterms.

  cmdline = {�[27;5;106~    enabled = false�[27;5;106~  },

My guess is that the new-line characters are being encoded with modifyOtherKeys or the Kitty keyboard protocol, and Neovim doesn't support that unless it enabled it.

[claytonchew]

For my case, I'm using nvim inside of tmux with Ghostty. By default, it could not register the key in nvim, hence I will need to add the following config to my tmux config:

set -s extended-keys on
set -as terminal-features 'xterm*:extkeys'

key works in nvim with the config, however, when I copy something like the following text:

a
b

And paste with CMD+v while in insert mode in nvim, I got this:

Previously I was using iTerm2, it did not give me issue, I'm not sure where to start figuring out what caused this. I'm aware of bracketed pasting, but this issue only happens if I use CMD+v directly while in Insert mode. The conventional "+P works fine.

[00-kat]

this issue only happens if I use CMD+v directly while in Insert mode. The conventional "+P works fine.

Aside: this is because in the former case, Ghostty sends the clipboard data to Neovim, while in the latter case, Neovim itself uses tools like pbcopy to grab the text from your clipboard.

[claytonchew]

*to further add

Turning off extended-keys by set -s extended-keys off on tmux config results in pasting with CMD+v works normally. So I'm not sure if that has an effect on its behavior.

[rbhanot4739]

This is the exact same workflow I have and exact same issue I am also facing.

[canova]

I think this is happening because tmux supports fixterms but not Kitty keyboard protocol. Or there is a bug somewhere in between. There is an issue in tmux for supporting kitty keyboard protocol but unfortunately it's closed: tmux/tmux#3335

This is the workaround that I found, which is not great but at least works, here's a diff in my tmux.conf:

-set -s extended-keys on
+# FIXME: extended-keys doesn't work with ghostty at the moment:
+# https://github.com/ghostty-org/ghostty/discussions/5924
+# https://github.com/tmux/tmux/issues/3335
+# set -s extended-keys on
+
+# This is a workaround while the extended-keys doesn't work with ghostty.
+# https://github.com/listx/syscfg/blob/ec89be49694f1befeb8a2dedaa46001632e41360/tmux/.tmux.conf#L360-L361
+# From https://github.com/alacritty/alacritty/pull/5358#issuecomment-1309433644
+bind-key -T root         C-S-j      send-keys Escape  "[106;6u"
+bind-key -T root         C-S-k      send-keys Escape  "[107;6u"

So basically I had to remove the extended-keys option since it's broken, and then add specific key bindings for my use cases that sends the escape sequence that I want. I stole it from here which has a lot more key combinations:
https://github.com/listx/syscfg/blob/ec89be49694f1befeb8a2dedaa46001632e41360/tmux/.tmux.conf#L360-L361
I only used two because these were only necessary for me, but you'll need to add more for your use cases.

[nyngwang]

I can confirm this after doing the same setup as OP.

On the other hand, forgiving my naive question: What are those neovim keybinds you're using that need set-option -g extended-keys always? Just asking. (am trying to help, but to do, so I need some specific examples for debugging.)

[claytonchew]

one example would be <C-CR> or Ctrl+Enter

[nyngwang]

Hi~ It seems that I have found a workable solution for the title. In short, you have to make sure your tmux is installed at HEAD. In my testing, I ran:

conda uninstall tmux
brew install tmux -s --HEAD

And make sure tmux -V prints tmux next-3.6 (or any future versions for sure). It has been working for me after the update. (since people, including me, would rarely install a package at HEAD from homebrew, we ran into the problem here.)

I hope this can work for OP and people in this thread.

EDIT: I should quote a line from the tmux project here. In short, we have to be patient on the next release (tmux 3.6 maybe) that includes this fix:

I also want to note here that tmux is a small, volunteer project and my time is often relatively limited, so as I of course much appreciate bug reports and particularly code contributions, I also appreciate patience if it takes a while to deal with them!

Note that as always due to limited time patch releases will only appear due to security issues or immediately obvious or showstopper bugs, so I encourage everyone to test the master branch ahead of the next release where they can.

source: tmux/tmux#4136 (comment)

I will put some links below in the details if you're interested in what I found/learned along the way, and the exact commit hash that tmux started to work:

Neovim added support for Super and Meta modifiers for TUI

neovim/neovim#24357, which was introduced in 2023/7.

Someone contributed to tmux to support "mode1", "mode 2" key-encoding

(I'm not sure whether this is related to "tmux's support for kitty's keyboard protocol" tho, but quoting for reference.)

The major change in this release is improved support for extended keys, thanks to Stanislav Kljuhhin. This moves tmux much closer to xterm's implementation of the feature for the mode 1 key encoding and adds support for mode 2. The extended-keys option remains, but if it is on or always then tmux will now turn on mode 2 by default rather than mode 1; applications may now request mode 2 - emacs does so, and I believe neovim as well. A new option extended-keys-format allows CSI u format to be selected, similar to xterm's formatOtherKeys resource.

source: tmux/tmux#4136 (comment)

The release was on 2024/9. From here, I also believed that there might be some inconsistency between Neovim or tmux regarding the encoding.

There was a problem similar to the one here, and the author said the patch was not included in tmux 3.5a

After reading some old-threads, I found tmux/tmux#4163 (comment), where people mentioned a very similar problem to the one here on 2024/10/5. Another issue also mentioned the exact commit where tmux resolved the issues, and it is 4f5d6d97.