Re: Selection changes in revno 100822

[David De La Harpe Golden <david@harpegolden.net>]

> Thanks, this clears up quite a bit of the confusion.  So would it be
> correct to modify the doc string of x-select-enable-primary to say
> this:
>
>     Non-nil means cutting text sets the primary selection.

[and pasting (yanking) gets from the primary selection.]

>     When the value is nil, the primary selection is still set by
>     selecting the text.
>

...if select-active-regions is t

As just mentioned elsepost, a third option other than nil and t, 'lazy, 
for select-active-regions was introduced recently, which means that 
mouse/shift selections do, but c-spc selections don't immediately, c-spc 
selections will defer setting primary to C-w/M-w time.

I don't like 'lazy.

> Why is it important not to touch the kill ring?
>

Well, if you do that, you break a conceptually straightforward 
kill-ring<=>clipboard mapping (that makes "turn on cua mode" somewhat 
useful advice to newbies who want to use C-x/c/v on x11) and pretty much 
depart from other-x11-app behaviour again.

>>> Thanks in advance for helping me become less confused.
>>
>> It is very confusing.  There are special cases depending on how the selection
>> was made, and then badly named variables increase the confusion.  Not to
>> mention trying to handle multiple platforms with differing capabilities.
>
> It seems to me that on platforms that have only one selection (the
> clipboard), selecting text should do nothing by default, while cutting
> should set the clipboard.

That sounds sensible to me, for the most part (there may be certain 
platforms that have an "only one selection (the primary)" - think gpm, 
where the user expectation would in fact be that mere selection of text 
changes the gpm "selection buffer" (as it is referred to in the gpm 
manpage) i.e. gpm happens to be more analogous to an x11 primary than an 
x11 clipboard, unlike the w32 clipboard where users generally do not 
expect mere selection of text to erase the previous clipboard contents).

w32 is the "odd one out" here of the x11/ns/w32 trinity.  I was rambling 
about ways to create an inter-application primary on w32 a while back, 
which caused you some puzzlement at the time.

Both x11 and ns platforms have functional inter-application 
clipboard/primary/secondary.  While other macosx apps may not typically 
use the latter two, they still work sensibly inter-session on macosx 
between emacs instances because of the way *step pasteboards work, and 
on gnustep/x11 they actually work in integrated fashion with x11 apps on 
the same desktop so long as you use the right pasteboard names,
which is neat.

>  And there should be a variable to
> optionally set the clipboard when the text is selected.  (Do we
> already have such a variable?

No, that would be the clipboard-active-regions I've mentioned before.

Some might have thought that's what x-select-enable-clipboard does, but, 
um, it doesn't, for similar reasons to x-select-enable-primary as just 
outlined by Jan D.

However, it used to "symptomatically" for mouse selections only on w32, 
because mouse selections used to implicitly copy 
(mouse-drag-copy-region=>t). That "copy" (kill-ring-save), as well as 
pushing to the kill-ring, called interprogram-cut-function, which set 
the clipboard when x-select-enable-clipboard is on.