Sync tmux clipboard and system clipboard

[Flakebi]

When copying, also write the content into the system clipboard.
When pasting, request tmux to refresh its paste buffer from the system
clipboard, wait for the update to propagate and the request the
clipboard content from tmux.

With set -g set-clipboard on in tmux, this enables sharing the
system clipboard with a helix running in tmux, running in an ssh
session, running in alacritty.

The need for a wait is unfortunate, but I didn't find a better way.
Tmux asks the terminal for the clipboard content and updates its buffer
after it got an answer. The answer may come or may not. It may take
long, e.g. when running through a slow ssh connection.

The feature works well on alacritty. On konsole, it doesn't do
anything, but doesn't harm either. On xterm, tmux refresh-client -l
prints gibberish for me, also without using helix, so I added an
option to disable this feature.

[archseer]

How about adding a editor.clipboard.paste/editor.clipboard.copy (now that I think about it, copy -> yank) section to the configuration? That way you're able to set this in config.toml

[Flakebi]

Hm, ideally I’d like the clipboard to just work out of the box. (Apart from this PR, there’s also OSC 52 support missing (which are terminal escape sequences), they are needed to support copy and paste e.g. in alacritty through ssh.)

How do you propose should the config look like if these commands should be used inside tmux, but the other built-in commands should be used outside tmux, e.g. when DISPLAY is set.

[pickfire]

If that config is enabled but tmux is not enabled won't it have an issue?

[Flakebi]

You mean with the tmux-system-clipboard from this PR? That shouldn’t be a problem. It’s only used when helix is running inside tmux.

With editor.clipboard.paste commands set in the config that are executed regardless of the environment that helix runs in, that would be a problem.

[Flakebi]

Rebased, no other changes

[archseer]

I don't like the delay this adds to pasting, it feels like a hack. Is there no better way to do this with tmux?

[Flakebi]

I don’t like it either, but I don’t know of a better way with tmux commands.
One example is running tmux over ssh. Calling tmux refresh-client -l triggers tmux to ask the terminal emulator for the current clipboard content.
After a network roundtrip, tmux updates its internal clipboard and tmux save-buffer - returns this content.
So, if the ping to the server is > 0.1 s, this will still paste outdated content. For a ping lower than that, it works.

As mentioned, the problem of not knowing when the clipboard updated exists when using tmux commands, but it can be circumvented by using a different method. There are the OSC 52 escape sequences that allow clipboard access by communicating with the terminal emulator.
tmux implements them as emulator and as client (tmux refresh-client -l triggers tmux to send such an escape sequence to the emulator).
The problems are

1. it requires a major rewrite to write and read from the terminal asynchronously (I did that in a branch a while ago master...Flakebi:clipboard52)
2. IIRC it had problems on terminals that don’t support OSC 52, i.e. it hangs on xterm. I tried solving that using a timeout, but it’s been so long, I don’t remember if it worked or not

Using OSC 52 to access the clipboard would be quite nice as it works when running helix over ssh, which currently doesn’t work (ssh -> tmux -> helix works with this patch though).

[pickfire]

So I guess now we just wait for OSC 52 and then only come back to this?

[archseer]

Resolved by #5027

[Flakebi]

#5027 only fixes the copy-path, not pasting. But as pasting works with ctrl+shift+v through the terminal, that’s fine enough.