[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Selection changes in revno 100822

From: David De La Harpe Golden
Subject: Re: Selection changes in revno 100822
Date: Sat, 14 Aug 2010 15:31:33 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100620 Icedove/3.0.5

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

    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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]