I was certain this was going to be an article about OSC52[1], which is a very widely supported ANSI escape sequence (basically invisible TTY terminal codes) that your terminal application (ITerm2, Alacritty, etc) listens for in order to place OSC52-wrapped text into the normal system clipboard. Because it's an invisible escape code (like colour codes) it works everywhere; shells, SSH, Mosh, tmux, vim, etc.
I assumed everybody and everything was heading towards this as a standard nowadays. But the article obviously demonstrates that that isn't the case. But the only reason it gives for not using OSC52 is that it has the potential to lag for large copy/pastes, which I've never (knowingly) experienced in quite some years of use. I assume there must be security implications too, but it doesn't go into them.
Considering the ubiquitous, consistent simplicity of OSC52 I would have thought it needed a lot more discussion in this article in order to justify the quite frankly surprising hoop jumping of the author's solution. I'm not saying it's unjustified, just that I need more contextualisation against what I consider the de facto standard for a unified TTY clipboard.
Same. I just learned about OSC52 a week or two ago and it was so easy and seemless to get working over SSH, through Tmux, inside of Vim (i.e. multiple layers of indirection).
I had no idea that OSC escape sequences were a thing until then and now I think they're the best.
This is what I do too, including hacking PuTTY to support it. I offered the patch upstream, but it seems they were not interested due to security concerns (even having it off by default). Fair enough, I suppose, but a man can dream...
I use this [0] vim plugin to copy and it works great. For the CLI in ssh I use this app [1]. Both leverage OSC52 escape codes which are widely supported by terminals nowadays.
Need to figure out an equally simple solution for CLI paste support though.
I just came across this blog post the other day, while trying to yank from nvim inside a container inside tmux. (It's my knowledge base, so not being able to copy/paste simply is quite annoying.) The clipboard doesn't exist if you're not using a windowing system, so I had to hook the Vim register to copy to a tmux register (and from there use pbcopy to get it to my macOS host).
> Until you close the app where you selected the text and now your clipboard is empty.
Ho, I used it for years, and you made me discover that strange property. Interesting.
> Or until you click somewhere, original app loses selection and your clipboard is now empty.
Yes, it's a very volatile clipboard, but if you expect your clipboard to have a lifespan greater than 5 seconds, you're probably doing something wrong.
You're both correct. Yes, it acts as a clipboard, for all practical purposes. But also it's a terminology thing.
If you'd open ICCCM, it uses name "CLIPBOARD" for a different selection atom: https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM...
So in X11 the term "clipboard" (in a technical, not colloquial sense) is reserved for a different selection. And thus primary selection is not a clipboard.
as someone who lives in vim (with a bunch of splits), often in ssh, copying things out of my editing session has a lifelong struggle (because selection doesn't understand splits).
this article is a good wakeup call, a reminder i've been living with a bad situation that deserves some attention.
Yes and no, at least for me, I have the option of printing whitespace chars as some printable ones (tabs vs spaces). Copying via tmux or the terminal emulator also pick them up, while yanking them on vim does not. Also I'm already too comfortable on vim yank keybindings, the combo yank with movements are very powerful
I try to re-arrange the split so that there are no vertical splits for the window I plan to copy from, but if you're using a terminal window in vim and want to copy text from it, you can use terminal normal mode and visual line selection to limit it to just the text you want to copy, even if you have a vertical split.
I actually use multiple terminals within gvim where I ssh to various hosts and use it to copy terminal scrollback text into the * or + register. This allows me to copy text from any terminal and paste it in Github or pastebin.
I can also copy text from any application and paste it in gvim either in a window or in a terminal running a shell or another program like a nested vim instance and paste the text from the * or + register (depending on how I copied it).
The only issue I have is linebreaks introduced by the terminal if I copy multiple lines of text. In that case, I paste the text in a gvim window, linewise visually highlight the pasted text and use the gJ combination to join all the lines without any intervening whitespace.
It's worked rather well for me for the last couple of years I've been doing it. Why would you consider it brittle?
I can use standard vim keybindings to copy text from the terminal to the clipboard:
ctrl-w N
?some text
shift-v
/some other text
"+y
Back when I used to use screen for a terminal buffer, the process was a bit more convoluted (copying the text to a screen register, writing it out to a file and reading the file into xclip IIRC). The experience just using (g)vim has been a lot better :)
Not exclusively. I just use it as the terminal multiplexer and as a way to copy text to and from any program running in one of its terminal windows. The only reason I use gvim instead of vim is because the latter isn't compiled with clipboard support (in the fedora package repository).
Distributed clipboard, mesh networking, xorg and Wayland integration. tmux and vim would also make sense, as OP has done, though I haven't gotten there yet.
`tmux -CC` is the best tmux experience I've seen, and it completely resolves the clipboard issues. Depends on terminal support.... But worth it: it's a seamless experience.
https://iterm2.com/documentation-tmux-integration.html
Is there some progress to make remote clipboard work for Wayland use case? So far I have to run the local terminal in XWayland more to be able to do ssh -X and sync remote clipboard in neovim to the local Wayland session. Having it all work without X would be neat.
Seems like a market opportunity here for an app that makes all of this work in a sensible way. Difficulty may be in making it possible to integrate into the target users' idiosyncratic editor+Linux tools setups though. And convincing said users to pay for something instead of hacking config files and scripts.
I mostly work in vim via ssh--occasionally inside a tmux session. Vim "paste mode", X11 selection, and OSC52 are built-in & have all my bases covered. I think this person is engaged in Rube Goldberg style procrastination.
OSC52 works for me in nested tmux sessions over SSH, and in TUI Emacs. Like that article mentioned, you need to explicitly tell tmux that your terminal supports OSC52.
I assumed everybody and everything was heading towards this as a standard nowadays. But the article obviously demonstrates that that isn't the case. But the only reason it gives for not using OSC52 is that it has the potential to lag for large copy/pastes, which I've never (knowingly) experienced in quite some years of use. I assume there must be security implications too, but it doesn't go into them.
Considering the ubiquitous, consistent simplicity of OSC52 I would have thought it needed a lot more discussion in this article in order to justify the quite frankly surprising hoop jumping of the author's solution. I'm not saying it's unjustified, just that I need more contextualisation against what I consider the de facto standard for a unified TTY clipboard.
1. https://oroques.dev/2020/11/27/vim-osc52.html