XTGETTCAP does not advertise osc 52 #2127

AtomToast commented 2025年06月02日 21:12:43 +02:00

Foot Version

foot version: 1.22.3 +pgo +ime +graphemes -assertions

TERM environment variable

foot

Compositor Version

river 0.4.0-dev.64+46f77f3

Distribution

Arch Linux

Terminal multiplexer

Shell, TUI, application

zsh, neovim

Server/standalone mode

• Standalone
• Server

Foot config

[main]
font=Hack Nerd Font:size=11,JoyPixels:size=11
pad=3x0 center
[colors]
regular0=282828
regular1=cc241d
regular2=98971a
regular3=d79921
regular4=458588
regular5=b16286
regular6=689d6a
regular7=a89984
bright0=928374
bright1=fb4934
bright2=b8bb26
bright3=fabd2f
bright4=83a598
bright5=d3869b
bright6=8ec07c
bright7=ebdbb2
foreground=ebdbb2
background=282828
alpha=0.98
[key-bindings]
spawn-terminal=Control+Shift+Return
show-urls-launch=Control+Shift+u
show-urls-copy=Control+Shift+l
unicode-input=Control+Shift+q
[url]
label-letters=tnseriaoplfuwydhvmck
[url-bindings]
toggle-url-visible=j

Description of Bug and Steps to Reproduce

When ssh'ing neovim should be able to automatically detect and activate osc52 as a clipboard provider. However this does not appear to work in foot.
When manually setting `vim.g.clipboard=osc52' it does work.

My issue matches the problem discussed in this issue: https://github.com/neovim/neovim/issues/29504
According to which you should execute printf '\x1bP+q4D73\x1b\\' in order to query XTGETTCAP. The expected result should resemble P1+r4D73=5C455D35323B25703125733B25703225735C303037.
The returned string from inside foot is P+q4D73.

In the linked issue, the problem ends up being iterm2 misreporting P0+r which apparently indicates that it doesn't support osc 52. Now I know very little about XTGETTCAP and don't actually know what these magic letters represent, so please excuse if I am wildly off here, but my best guess is that the foot string doesn't advertise foots osc 52 capability either. This seems to be not an uncommon issue since there are also matching issues referenced for windows terminal and zellij

Relevant logs, stacktraces, etc.

No response

### Foot Version foot version: 1.22.3 +pgo +ime +graphemes -assertions ### TERM environment variable foot ### Compositor Version river 0.4.0-dev.64+46f77f3 ### Distribution Arch Linux ### Terminal multiplexer - ### Shell, TUI, application zsh, neovim ### Server/standalone mode - [x] Standalone - [x] Server ### Foot config ```ini [main] font=Hack Nerd Font:size=11,JoyPixels:size=11 pad=3x0 center [colors] regular0=282828 regular1=cc241d regular2=98971a regular3=d79921 regular4=458588 regular5=b16286 regular6=689d6a regular7=a89984 bright0=928374 bright1=fb4934 bright2=b8bb26 bright3=fabd2f bright4=83a598 bright5=d3869b bright6=8ec07c bright7=ebdbb2 foreground=ebdbb2 background=282828 alpha=0.98 [key-bindings] spawn-terminal=Control+Shift+Return show-urls-launch=Control+Shift+u show-urls-copy=Control+Shift+l unicode-input=Control+Shift+q [url] label-letters=tnseriaoplfuwydhvmck [url-bindings] toggle-url-visible=j ``` ### Description of Bug and Steps to Reproduce When ssh'ing neovim should be able to automatically detect and activate osc52 as a clipboard provider. However this does not appear to work in foot. When manually setting `vim.g.clipboard=osc52' it does work. My issue matches the problem discussed in this issue: https://github.com/neovim/neovim/issues/29504 According to which you should execute `printf '\x1bP+q4D73\x1b\\'` in order to query XTGETTCAP. The expected result should resemble `P1+r4D73=5C455D35323B25703125733B25703225735C303037`. The returned string from inside foot is `P+q4D73`. In the linked issue, the problem ends up being iterm2 misreporting `P0+r` which apparently indicates that it doesn't support osc 52. Now I know very little about XTGETTCAP and don't actually know what these magic letters represent, so please excuse if I am wildly off here, but my best guess is that the foot string doesn't advertise foots osc 52 capability either. This seems to be not an uncommon issue since there are also matching issues referenced for windows terminal and zellij ### Relevant logs, stacktraces, etc. _No response_

krobelus commented 2025年06月02日 22:34:47 +02:00

foot does advertise the capability, but the response format is different:

$ printf '\x1bP+q4D73\x1b\\'; cat -v
^[P1+r4D73=1B5D35323B25703125733B25703225731B5C^[\
$ python
>>> [bytes.fromhex(s) for s in "4D73=1B5D35323B25703125733B25703225731B5C".split("=")]
[b'Ms', b'\x1b]52;%p1%s;%p2%s\x1b\\']

compared to the response you mentioned is expected by Neovim:

>>> [bytes.fromhex(s) for s in "4D73=5C455D35323B25703125733B25703225735C303037".split("=")]
[b'Ms', b'\\E]52;%p1%s;%p2%s\007円']

so that's \\E (two characters) instead of the raw escape byte (\x1b), and an (escaped) alternative sequence terminator instead of \x1b\\. This is what kitty sends.

The difference in output format is odd but as far as I can tell, apps should probably ignore the value part (after the =) and only check whether the response is successful or not -- since I don't think there is a reason for any terminal to use a different sequence.

foot does advertise the capability, but the response format is different: ``` $ printf '\x1bP+q4D73\x1b\\'; cat -v ^[P1+r4D73=1B5D35323B25703125733B25703225731B5C^[\ $ python >>> [bytes.fromhex(s) for s in "4D73=1B5D35323B25703125733B25703225731B5C".split("=")] [b'Ms', b'\x1b]52;%p1%s;%p2%s\x1b\\'] ``` compared to the response you mentioned is expected by Neovim: ``` >>> [bytes.fromhex(s) for s in "4D73=5C455D35323B25703125733B25703225735C303037".split("=")] [b'Ms', b'\\E]52;%p1%s;%p2%s\007円'] ``` so that's `\\E` (two characters) instead of the raw escape byte (`\x1b`), and an (escaped) alternative sequence terminator instead of `\x1b\\`. This is what kitty sends. The difference in output format is odd but as far as I can tell, apps should probably ignore the value part (after the `=`) and only check whether the response is successful or not -- since I don't think there is a reason for any terminal to use a different sequence.

dnkl commented 2025年06月03日 06:56:56 +02:00

Relevant issue behind the change in foot: #1701, and the corresponding PR: #1703

Relevant issue behind the change in foot: https://codeberg.org/dnkl/foot/issues/1701, and the corresponding PR: https://codeberg.org/dnkl/foot/pulls/1703