Re: Selection changes in revno 100822

[David De La Harpe Golden]

On 14/08/10 16:18, Eli Zaretskii wrote:

> You mean, non-nil, right?  At least in deactivate-mark, we have this:

No, I didn't.  whether t or 'lazy the current code still does it in 
deactivate-mark (possibly unnecessarily or even counterproductively in 
the the t case, I'm not currently sure), the t/lazy difference is 
elsewhere (keyboard.c line 1798 or so).

('lazy was not my idea, that's just my understanding)

> But pasting gets from the primary selection unconditionally, so it
> seems.

No, mouse-2 clicking does. pasting (C-y/ CUA C-v) doesn't.

mouse-2 click insertion and clipboard pasting are not equivalent on x11. 
If you think they are, then that surely would lead you to be confused.

> IMO, whenever there's only one selection, its name, whether primary or
> clipboard, is not important.

Users have different expectations of clipboards and primaries. Following 
de-facto standard in the area:

clipboards aren't overwritten when you merely select text.
clipboards are overwritten when you cut/copy (C-x/C-c)
clipboards are not inserted when you click mouse-2.
clipboards are inserted when you paste (C-v)
(w32 clipboard, ns general pasteboard, x11 clipboard*).

primary selections are overwritten when you merely select text.
primary selections are not overwritten when you cut/copy (C-x/C-c) (but 
they've probably already just been overwritten because you selected text 
just before you cut/copied).
primary selections are inserted when you click mouse-2.
primary selections are not inserted when you paste (C-v)

(like x11 primary selection, ns "Selection" pasteboard, gpm selection 
buffer)

So if emacs does anything other than clipboard<=>kill-ring, then
"cua mode" is not an answer, since if emacs C-w/M-w/C-y doesn't act like 
other-app C-x/C-c/C-v, making emacs C-x/C-c/C-v act like emacs 
C-w/M-w/C-y still doesn't make emacs C-x/C-c/C-v act like other-app 
C-x/C-c/C-v.

> Why do we need a separate variable for the clipboard on w32? why not
> reuse select-active-regions?

Why have the same setting do such grossly different things on different 
platforms?

> So maybe we should continue setting the clipboard data on selecting
> text, since w32 users always had that (mis-)feature.  They are used to
> it.

By all means have a clipboard-active-regions that defaults to t on w32 
if you want, but please do not reinterpret select-active-regions to 
affect the clipboard on w32.  You'd be making it gratuitously impossible 
to have the 3 gui platforms behave similarly given similar settings.

I'm not an emacs committer, just a contributor.  I can just go back to 
maintaining my own emacs branch with beer and hookers.  But once again 
I'd ask you not to use the name select-active-regions but rather 
clipboard-active-regions or similar for a feature that ...makes the 
active region got to the system clipboard, not the system selection..

Note such a feature also makes sense to provide on x11, there's an old 
guard who dislike the way x11 apps currently use primary/clipboard and 
x11 emacs users are more likely to be in that old guard than most.


* which happens to be /implemented with/ an "x11 selection thingy" 
(let's say a "rhubarb").  But so is, say, the protocol for deciding what 
x11 client is the active window compositing manager...(done with rhubarb 
'_NET_WM_CM_Sn rather than 'CLIPBOARD or 'PRIMARY or 'SECONDARY.)

rhubarbs are thingies x11 programs can "own" (beware this is not 
entirely equivalent to the w32 notion of clipboard ownership)

rhubarb 'PRIMARY implements the system notion of a known 
current/most-recent selection. The current owner of this rhubarb is who 
to ask for
the current/most-recent selection.

rhubarb 'SECONDARY implements, uh, another selection that people seldom 
use (alt-mouse-drag/alt-mouse-2 in emacs).  The current owner of this 
rhubarb is who to ask for the current/most-recent secondary selection.

rhubarb 'CLIBPOARD implements the system clipboard.  The current owner 
of this rhubarb is who to ask for the clipboard contents.

rhubarb '_NET_WM_CM_S0 implements the system notion of who is the 
current compositing manager for screen 0. The current owner of this 
rhubarb is who gets to be the current compositing manager.