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 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