helix
helix copied to clipboard
helix-editor
Use OSC 52 as a fallback for setting the system clipboard
This emits an OSC 52 terminal code for copying into the system terminal if we don't find a local provider. That gets setting the local clipboard to work through SSH.
It doesn't do the get clipboard side of OSC 52 for a few reasons:
- OSC 52 get isn't often enabled as it's a security hole that lets remote terminals read your local clipboard
- It'd require getting the clipboard to be async since we'd need to wait for the terminal response
- Getting the clipboard is way less useful since you can go into insert and use your OS-level paste command to simulate it
vim-oscyank has this nice list of supported terminals. I've tried it on Kitty on Mac and it seems to work well. I believe the primary vs clipboard type selection codes are correct, but I'd need somebody on Linux to let me know if it's working as expected.
oscyank emits a tmux-specific code to get it to work in tmux. Since we already have a tmux specific implementation, I didn't attempt to add that. I don't use tmux enough to know if OSC 52 would be better for it than the tmux load-buffer call we're currently making.
Getting the clipboard is way less useful since you can go into insert and use your OS-level paste command to simulate it
#2239
Heh, I guess I hadn't done much pasting of large text. It had been fine with the smaller things I pasted, but yeah, that's painful.
Your suggestion of bracketed paste does seem like a better way to solve slow pasting than OSC 52. Just opened https://github.com/helix-editor/helix/pull/3233 to enable bracketed paste.
I've opened https://github.com/crossterm-rs/crossterm/pull/697 to move the OSC 52 command into crossterm. Once that's released, I'll switch this code to use it.
In the meantime, I think this is ready for review and possible merging.
Given that we're only using the base64 dependency for base64-encoding a &str, I don't think it's worth pulling in a whole crate. A base64 encoding function can be added in-line in probably less than 100 lines of code.
Given that we're only using the
base64dependency for base64-encoding a&str, I don't think it's worth pulling in a whole crate. A base64 encoding function can be added in-line in probably less than 100 lines of code.
Just did this. I got the implementation in in 60 lines, though it's over double that with tests.
Would this also obsolete https://github.com/helix-editor/helix/pull/1343 ?
Would this also obsolete #1343 ?
I think maybe? It's complicated and I'm not a tmux user, so I'm just basing this answer on reading their docs and may be getting it wrong.
From tmux's clipboard docs, it sounds like if set-clipboard on is set for tmux, tmux would pass the OSC 52 Helix emits through to the surrounding terminal and set the system clipboard.
As of tmux 2.6 from a few years ago, the default for set-clipboard is external. That means that tmux itself can emit OSC 52 codes but that it eats them from applications to keep them from modifying the system clipboard. That means tmux users would need to configure set-clipboard to use this.
In this PR, we only use OSC 52 as a fallback if we don't find a "native" clipboard provider. We look for the TMUX env var and tmux executable and use that as a native provider if we find them. That means we wouldn't emit OSC 52 in that case.
Putting it all together, I think that means this could handle the clipboard setting part of #1343 if the user has set set-clipboard on in their tmux and we use OSC 52 in preference to setting tmux's internal paste buffers.
I think it might make sense to add an option to use OSC 52 regardless of what's available locally. That way a tmux user that wants to configure that can, and people who have X or Wayland installed on a server they're SSHing into can choose to use OSC 52 if they're not forwarding X. I was loathe to add configuration, but this seems like something that's impossible to guess from just what's on the system.