Support clipboard via OSC 52

[yurikhan]

Many terminal emulators, starting with Xterm, conditionally allow access to the system clipboard via an escape sequence. In comparison with xclip-based solution (#30), this works transparently when you ssh around, without X11 forwarding and without having to install xclip on each server you manage.

To write to the clipboard, an application sends ESC ] 5 2 ; c ; <content> ESC \, where <content> is base64-encoded. (BEL can also be used as terminator.)

To read the clipboard, an application sends ESC ] 5 2 ; c ; ? ESC \. A conforming terminal will respond by sending ESC ] 5 2 ; c ; <content> ESC \, again, with <content> base64-encoded. (If the request uses BEL instead of ESC \, the terminal’s response will typically also be terminated with BEL.)

A non-supporting but ANSI-conforming terminal will ignore the unsupported OSC sequence until the ESC \ or BEL terminator.

I do not think there is a termcap/terminfo capability advertising support, so it would probably have to be a user option. Alternatively, mc could unconditionally put copied content into both ~/.local/share/mc/mcedit/mcedit.clip and send the OSC sequence; when pasting, first send the request, and if no response within a few milliseconds, fall back to reading ~/.local/share/mc/mcedit/mcedit.clip.

[zaytsev]

Wow, this would be cool! What do you think andrew_b? I wonder what's the current state of the terminal support for this feature...

[yurikhan]

I must admit my “Many terminal emulators” assessment is skewed towards emulators aimed at power users. Xterm (opt-in via config), Kitty (opt-in via config), Alacritty, iTerm2 (warns); tmux (opt-in via config). Support in libvte and KDE’s implementation seems to be stuck on the security issues; basically, “a compromised ssh server could steal passwords by polling your clipboard” and “a compromised ssh server could put a malicious command into your clipboard which you might then execute locally or on a different server”.