@BRicker @technicalotter @nokke

There are three things, and my approach isn’t ideal for all of them:

The first is being able to select and copy text without moving the insert point. This is more useful for code than prose, but I find this incredibly useful. Acron’s RiscOS did this as the system level. If you selected with the left mouse button, it moved the cursor to the selection (so you could overwrite by typing). If you selected with the right mouse button (middle brought up the menu), it created the selection but didn’t move the cursor, so you could easily copy from the selection and paste at the cursor. I have never seen any other system do both well. Vim in a terminal does one well with mouse support enabled and the other well with most support disabled. This is a tradeoff and it’s obvious that picking only one will not work for everyone (which is a shame because almost every other text box on almost every OS picks one without considering the tradeoff).

The second is having more than one clipboard. Again, this is something that is generally useful. And, in fact, two isn’t great. Emacs, I believe, lets you have multiple. I think there’s even some way of doing this in vim. It’s pretty much essential to have more than one in vim because vi conflates delete and cut, so if you want to copy something, delete something else, the paste, it!s clunky. Using a second clipboard makes this less clunky (though using the system clipboard via the terminal means you sacrifice the ability to use macros, which is annoying). The OS I’ve seen with the nicest approach to multiple clipboards was the Newton. You didn’t have a system clipboard as a user abstraction, you just dragged things to the edge of the screen. It then appeared as a little tab and you could switch applications and drag it back to paste. Direct manipulation all of the way.

The third is having a private-to-the-editor clipboard. This is useful only intermittently, but sometimes I ‘yank’ something in vim, then need to do something else before pasting it and that may involve copying and pasting between other applications. Many, many years ago, I built a little proof of concept that treated the clipboard as a stack. If you copied nothing, it popped the top entry from the stack, otherwise each new copy pushed the previous copied thing and each past would use the top element. It worked nicely and would have solved this problem, especially if you had a ‘pop everything until you get to the last thing the active clipboard client copied’ (or even ‘duplicate the last thing the active clipboard client copied to the top of the stack’) as operation.

As with many other things I do on computers, I’m working around the fact that the systems don’t provide the right UI abstractions to solve the problems I actually have and am getting the closest approximation. And it’s not good, it’s just better than nothing.