copy and paste keeps getting worse

 Copy and paste on linux-based OSs is getting steadily worse.

One or two debian releases ago, copy and paste broke on vim, which, via vi, was my main editor.  Every time I had a terminal with a vi running inside, and I tried to paste in text using the middle mouse button, it didn't work.  Instead, vim gave some error about nothing or something and registers, and probably beeped as well.  The proximal "fix" was to configure vim not to have this idiotic behaviour (really?), or change the system vi to some other vi.  A longer-term fix would be to purge the OS of the software responsible, and root out any other software by the same authors.

Just now I have gone to copy some information from a firefox browser window to an editor in a terminal running vi.  I select the text in firefox.  I go to the terminal and click the middle button.  This is copy and paste should work under X.  Something gets pasted in, but it's some other piece of text.  I go back to the browser and select the text I want.  I middle-click in the terminal.  Same other text.  At this point, I have to take a decision.  I can either debug this copy and paste thing, or just go ahead and type out the information by eye from the browser to the editor.  Pragmatically, my choice is to type out the information by hand.  This is computing in the twenty-first century.  While everyone has been "working" on their animated transition effects and whitespace, basic functions like copy and paste simply don't work.

Copy and paste in Unix is more or less copy and paste in X, or X11.  This is possibly the first design issue.  Instead of there being a session clipboard, there is an X session clipboard.  In a nicely-designed system, a user who has launched X themselves should be able to quit X, and, still in the same session, be able to paste.

X seems to have two clipboards on the go.  One is copied to by mere selection, for example by selecting text, and pasted with the middle mouse button.  This is brilliant but only if it works all the time.  The other is copied to by more MS-Windowsy applications, for example GNOME, KDE, office packages, and so on, with Ctrl-C or edit->copy or select->right-click->copy.  Paste is with Ctrl-V, edit->paste, or right-click->paste.

Sometimes, copying something into the MS-Windows-style clipboard will make it available for pasting with the middle button.  When this happens, it's not clear whether it was a side-effect of selection, or some kind of deliberate copying to both clipboards by the application.  There isn't enough observable consistency to try and rely on this happening.  But sometimes, when selection has failed to make the text available for pasting with the middle button, going back and pressing ctrl-c can make that text go into X11-y clipboard, where mere selection failed.  This is sometimes worth a go when the other thing isn't working, depending on whether you feel like typing something out by hand, whether it seemed to work last time, and so on.

Conversely, just selecting text doesn't seem to make it available for pasting with ctrl-v.

As usual, emacs has its own thing going on, and its interactions with these two copy and paste systems are arcane, add further complexity, and would take substantial archaeology and experimentation to start building any description.  emacs went through a phase of requiring extra configuration just to have middle-click work, just like vim is doing now, but that phase now seems to be passed.

Browsers have their own things going on too. The most common thing you want to copy out of a browser is the URL.  In firefox, clicking once selects the URL, but, critically, does not copy it to the X clipboard.  At this point, clicking again deselects the URL.  Double-clicking selects a small part within it, apparently according to normal gtk text-selection double-click rules.  Triple-clicking selects the whole URL and puts it in the clipboard, which is what we want.  This is consistent with the Unixy "triple-click to select a whole line" UI pattern, but, if it's selecting on single-click, why not allow it to go in the clipboard?  It would by default, so they must be going to extra effort to avoid this happening.

Chromium is somehow similar, but I can't remember the exact details.

Moving back up from particular applications to the framework, middle-click is often inconvenient or ineffective.  For some reason, X never got a standard paste key (combo).  The X standard way was middle-click, on the mouse, and nothing on the keyboard.  I'm sure it's easy enough to configure a paste button within X, but I imagine this is done via the window manager, and is not possible at the X level.  There is no reason to have a standard mouse button for paste and not a standard keyboard button.  It results in switching to mouse just to paste, even when you're doing everything else with just the keyboard.  And often the text cursor is in just the right place to paste.  To paste in the right place, you have to re-aim the mouse cursor just where the text cursor is, and click there.  How many billions of times has this re-aiming been carried out by users, without someone going "I'll make a thing, and that thing will have a standard keyboard paste which is just like a standard middle-button mouse paste"?

The main issue with the Windowsy parallel system is that it requires application support.  X copy and paste happens at the X level, and this is why it used to have this wonderful universal feel to it.  Ctrl-C Ctrl-V doesn't.  The other issue is the inefficiency of select and hit a two-button combo, vs just select.

And why does the X one no longer have the universal feel?  If a complicated application wants to try hard enough to not have this work, then it can stop it working.  It was just kind of "universal by default", not "universal with no way out".  And when there's a way out, complicated application developers just can not resist finding that way out, because they think they're special, or because they have to meddle.  If there was a way out from the universal interface for terminating the process, kill -9, thousands upon thousands of special developers would cruft up their individual codebases with simlar ways of exercising this way out.

When it comes to text selection, or even treating text as text, there is no way out of having a way out.  Ultimately, an application developer bent on not working with the system copy-and-paste, can pretend it's all pictures, render text to pictures, and show the "pictures".  Since in practice there is plenty of content exactly like that, from photos and scans and screenshots to deliberately-obscured web "content", it does raise the question of whether OCR should be built in at the windowing-system level.  But that is way ahead.

I just did it!  I did ctrl-c in firefox and middle-click in vim.  But the status bar now says "INSERT (paste)", which indicates something is being too clever.  I dread to think what is actually happening in order for this to have happened to have "worked" in this particular case.

When I make my OS, I'd like to have a display of the main clipboard(s) as part of the always-shown WM furniture.  This could have a fixed-size mini rendering, and multiple media types, not just plain text, could be displayable. That way, the user can monitor in real time whether their selections are working as intended, what things are going to both clipboards, and thus what the result of any paste operation is likely to be.  I'll also have a paste keyboard key or combo built in by default.  

Further in the future, it may be possible to replace the X mechanism with a generic session mechanism, find a way for this to make sense within a terminal emulator console, and somehow unify copy and paste across terminal consoles, X consoles, and whatever else consoles.  Again, way ahead. For now, I would be happy just to be able to copy these here three short pieces of textual information from this here email to this here text file.