Re: Selection changes in revno 100822

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 14 Aug 2010 15:31:33 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: Jan Djärv <jan.h.d@swipnet.se>, 
>  cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> 
> > 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.]

But pasting gets from the primary selection unconditionally, so it
seems.  E.g., under the default nil value of x-select-enable-primary,
mouse-2 still pastes from the primary selection.  That's why I didn't
mention pasting in the suggested modification of the doc string.  Am I
missing something?

> >     When the value is nil, the primary selection is still set by
> >     selecting the text.
> >
> 
> ...if select-active-regions is t

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

  (when (or transient-mark-mode force)
    (when (and select-active-regions   <<<<<<<<<<<<<<
	       (region-active-p)
	       (display-selections-p))
      ;; The var `saved-region-selection', if non-nil, is the text in
      ;; the region prior to the last command modifying the buffer.
      ;; Set the selection to that, or to the current region.
      (cond (saved-region-selection
	     (x-set-selection 'PRIMARY saved-region-selection)
	     (setq saved-region-selection nil))
	    ((/= (region-beginning) (region-end))
	     (x-set-selection 'PRIMARY
			      (buffer-substring-no-properties
			       (region-beginning)
			       (region-end))))))

Is this a bug or intended behavior?

> 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.

And I don't like in general the situation where it seems impossible to
say if and when will selected text be put into the primary selection.

May I suggest to step back and post a clear set of requirements for
when Emacs should and shouldn't put selected text into the primary
selection and into the clipboard?  Forget the w32 case for now; let's
just spell out the requirements for X.

> > Why is it important not to touch the kill ring?
> >
> 
> Well, if you do that, you break a conceptually straightforward 
> kill-ring<=>clipboard mapping

What mapping is that?  Do you mean that only killed text goes to the
clipboard?  If so, that's fine, but I wasn't talking about the
clipboard.  I was talking about the primary selection on X and about
platforms that don't have any selections at all.  I was wondering why
is it important to stay away of the kill-ring like mouse-yank-primary
does, instead of doing it like mouse-yank-at-click, which was
previously bound to mouse-2?

> and pretty much depart from other-x11-app behaviour again.

What behavior is that?  What other apps have something similar to the
kill ring?

> 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).

IMO, whenever there's only one selection, its name, whether primary or
clipboard, is not important.  Thus, GPM can be thought of as being
like w32, not like X, because the distinction between the primary and
all the other selections is null and void.

IOW, the clipboard-related behavior of Emacs on Windows should be the
same as what Emacs does on X wrt the primary selection.

> >  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.

Why do we need a separate variable for the clipboard on w32? why not
reuse select-active-regions?  The amount of subtly dependent variables
that control the behavior regarding selected text wrt selections is
already too large, why introduce yet another one?

> However, it used to "symptomatically" for mouse selections only on
> w32, because mouse selections used to implicitly copy
> (mouse-drag-copy-region=>t).

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.