`plugin/osc52.lua` still cannot set `vim.g.clipboard` on tmux under SSH

[przepompownia]

Problem

As in the title, I cannot get plugin/osc52.lua working on the remote host inside tmux.

There is no problem if I open nvim in a remote shell without tmux.

cc @gpanders

Steps to reproduce

All on the remote (Debian) host accessed by SSH:

tmux.conf:

set-option -g allow-passthrough on
set -g set-clipboard on
set -ga terminal-overrides "screen*:Ms=\\E]52;%p1%s;%p2%s\\007,tmux*:Ms=\\E]52;%p1%s;%p2%s\\007"

osc52-tmux.lua (contains manual check because on UIEnter was too early to get vim.g.clipboard):

local function test()
  vim.print('SSH_TTY: ' .. os.getenv('SSH_TTY'))
  print('clipboard: ' .. vim.inspect(vim.g.clipboard))
  -- vim.cmd([[au TermResponse]])
  vim.print(vim.api.nvim_get_autocmds({event = 'TermResponse'}))
end

vim.api.nvim_create_user_command('Test', test, {})

# without tmux
~/path/to/bin/nvim --clean -u osc52-tmux.lua
# with tmux
tmux kill-server; tmux new-session -- ~/path/to/bin/nvim --clean -u osc52-tmux.lua

• run :Test inside both nvim instances.

Expected behavior

vim.g.clipboard is set by plugin on tmux under SSH without need to set it manually.

Neovim version (nvim -v)

NVIM v0.10.0-dev-1694+gaa9d9cafd

Vim (not Nvim) behaves the same?

-

Operating system/version

Debian Sid

Terminal name/version

tmux 3.3a-5 (on remote host), kitty 0.31.0 (on localhost)

$TERM environment variable

tmux-256color

Installation

from repo

[przepompownia]

On non-clean nvim:

[przepompownia]

If I did not any mistake, it looks like

io.stdout:write('\027Ptmux;\027\027P+q4D73\027\\\027\\') 

does not trigger TermResponse in effect.

[gpanders]

Thanks, I can reproduce this easily in Kitty. All that's needed to reproduce is:

kitty --config=NONE
tmux
printf '\ePtmux;\e\eP+q4D73\e\\\e\\'

Kitty shows an error:

[PARSE ERROR] DCS sequence contained ESC without trailing \ at pos: 7 ignoring the sequence

[gpanders]

I think this is a kitty bug, since the exact same sequence works as expected in every other terminal I've tried (WezTerm, Ghostty, iTerm2).

It's also possible the other terminals are doing something incorrectly and that kitty is the only one doing the right thing. In the tmux server log I see the following:

1701268309.756007 input_parse_buffer: %0 ground, 374 bytes: \033Ptmux;\033\033P+q4D73\033\\\033]133;D;0\a\033[?1004h\033[2m\342\217\216\033[m\017                                                                                                                                                                                                                                                                                                                              \r\342\217\216 \r\033[K
1701268309.756014 input_enter_dcs
1701268309.756023 input_dcs_dispatch: "tmux;\033P+q4D73"
1701268309.756031 /dev/ttys009: \033P+q4D73

It's possible it just isn't being logged, but it's not showing the \033\\ terminator for the DCS sequence. So it might be that kitty's parser is stricter (it refuses to parse a DCS without a terminator) while the other terminals are less strict, and this is a bug in tmux that it is not forwarding the DCS terminator to the terminal.

Actually I'm now quite sure this is the case, because in both WezTerm and Ghostty the DCS sequence is not required to be terminated. So tmux is not including the "inner" DCS terminator from the original sequence and kitty is refusing to parse it. This is a tmux bug.

[gpanders]

Linked tmux issue here: https://github.com/tmux/tmux/issues/3755

In any case, there is nothing that Neovim can do about this. Please follow the tmux issue.

[gpanders]

In any case, there is nothing that Neovim can do about this.

I stand corrected, we need an extra escape.

[przepompownia]

@gpanders thanks for investigation. Now setting vim.g.clipboard simply works for me there! I don't have to set it manually or in my configuration.

I wasn't sure how sufficient my reproduction condition was, so I'm also glad you were able to reproduce it.