This has been bugging me for a while now, and I just figured out what conditions cause it, but I don't know why, and if there is a (desired) workaround.

The cause is quite obvious when there are two windows side by side... Select text in one window, and the other window's selection becomes unselected... I always work at full-screen (17" monitor), so I was a bit slow on the uptake.

I assume that this has something to do with the primary selection mode of X, but I don't understand, why each window can't at least keep its text highlighted even it it isn't actually in the primary buffer (or is the primary buffer actually the highlighted text itself?)...

Programs such as Firefox manage to maintain the current "selection" under similar conditions, so it is possible. Why does this behaviour of de-selection exist (at all) ?

I find the primary selection to be useful, but I do use the clipboard more often (probably, because of issues like this), I wonder: is there some way to disable the X's primary selection mode--if that is the only workaround.. It may be too drastic, but I'd like to try it, if it's the only way.


If you select text with simple drag, it goes into what I usually call the 'soft' buffer - you can paste it with a simple middle mouse click, but the moment you select anything else it's gone.

On the other hand, gnome and KDE and other WMs generally also let copy selected text into a 'hard' buffer where it stays until you explicitly copy something else into it.

Programs like Firefox don't so much maintain the Xorg selection as that they add a selection mode of their own that just happens to coincide with it -- for example, if you select text in firefox, then select something in another window, then go back to FF and middle click to paste, you'll get the latter text.

  • 1
    Gotta love the many clipboards of Linux. Then there's the BASH kill ring. – amphetamachine Jul 25 '11 at 8:27
  • Thanks Shadur.. It seems it's something I just need to live with.. Now that I understand why it happens, I can better avoid the pitfalls... I've been testing some of my1 apps, and only 3 out of 27, tested so far, don't upset the X-selection... Even Firefox upsets the boat via its edit-fields and dialog-boxes.. gvim causes selection loss... and emacs does, but only via data going to its kill-ring... so this is definitely tightly locked into X, and that's that! :)... – Peter.O Jul 26 '11 at 1:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.