[prev] [thread] [next] [lurker] [Date index for 2004/10/08]
Zack Weinberg writes: > The primary selection is supposed to always be the same as the text which > was most recently selected with click-and-drag. It is not supposed to go > away just because I clicked in some other window. It probably shouldn't > go away even if the most-recently-selected text is no longer highlighted. > It *should* go away if the window in which text was most recently selected > no longer exists. Middle-mouse paste is only supposed to paste the > primary selection; not the clipboard and not anything else either. Yes. Yes, yes, and yes again. Moreover, if application A owns the PRIMARY selection, it should offer a 'Copy' operation which copies it to the CLIPBOARD selection, so that it survives after you've selected something else. And applications should distinguish middle-click paste (for the PRIMARY selection) and menu-item paste (for the CLIPBOARD selection). This is how it's meant to work. http://www.freedesktop.org/standards/clipboards-spec/clipboards.txt > (special bonus Emacs hate: if some other client asserts the primary > selection, not only should the client that currently has it drop it, it > should *stop highlighting stuff as if it were selected*. I.e. the > transient mark should be cancelled. And then C-x C-x should *reassert* > the primary selection.) Oh, there's way more than that to hate in GNU Emacs's selection handling. The most insane bit is that M-Backspace (the obvious and natural way of deleting the word to the left of point) actually steals the PRIMARY selection. This is because Emacs has an incredibly half-baked idea that the PRIMARY selection should be unified with the top of the kill-ring. This doesn't work. For example, even with transient-mark mode, selecting a region doesn't assert the PRIMARY selection. No, you have to M-w (the equivalent of menu-item Copy) to do that. Duh. Now, Emacs is programmable, so in theory you can fix all of this. In practice, however, it's not quite good enough. I don't have all the details now, but when I last tried, there were bugs in the C-implemented functions that prevented it from working correctly. According to my notes, when you tell Emacs to disown the PRIMARY selection, it does all the X bits correctly, but fails to update its internal cache, so it believes it's still the owner of the PRIMARY selection even though it isn't. And why should it have an internal cache of who owns which selection? The claim is that it reduces X traffic when you're on a slow link. Mmm, possibly, but perhaps not as much as NOT ASSERTING THE PRIMARY SELECTION EVERY TIME I DELETE A SODDING WORD! Hate. -- Aaron Crane
Generated at 18:01 on 11 Oct 2004 by mariachi 0.52