[Top][All Lists]

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

Re: Selection changes in revno 100822

From: Eli Zaretskii
Subject: Re: Selection changes in revno 100822
Date: Sat, 14 Aug 2010 11:00:04 +0300

> From: Chong Yidong <address@hidden>
> Cc: address@hidden
> Date: Fri, 13 Aug 2010 21:08:51 -0400
> Eli Zaretskii <address@hidden> writes:
> Thanks for looking through the changes.
> >   . Why was mouse-drag-copy-region changed to default to nil?  This
> >     variable doesn't seem to be related to selections, but rather to
> >     the kill ring.
> IIRC, this was part of the attempt to cut down on the special casing
> involved in mouse drags.  It is not consistent with shift-selection, for
> instance.

Perhaps we should solve this inconsistency the other way around: have
shift-selected text be copied (under control of the same variable).
But that is unrelated to the main issue of this thread; I personally
have no problems with the new default.

> > . The change in binding mouse-2 to mouse-yank-primary instead of
> >   mouse-yank-at-point, in addition to referencing only the primary
> >   selection, means one more change: mouse-2 no longer yanks the last
> >   kill, except through the primary selection.  Is this change in
> >   behavior intentional, and if so, what is the reason behind this
> >   change?
> I assume you mean mouse-yank-at-click.

Yes, sorry.

> The change is intentional.  The
> standard behavior of other X applications is for mouse-2 to insert
> primary.  mouse-yank-at-click calls yank, but since
> x-select-enable-primary is now nil, that does not insert primary.

I'm utterly confused now.  The doc string of x-select-enable-primary

  Non-nil means cutting and pasting uses the primary selection.

According to this, the value of nil, the current default, means
"cutting and pasting do NOT use the primary selection", right?

But OTOH, the NEWS entry says something contradictory:

  The way Emacs interacts with the clipboard and primary selection, by
  default, is now similar to other X applications.  In particular, kill
  and yank use the clipboard, in addition to the primary selection.

The last sentence seems to say that kill and yank still do use the
primary selection, and _in_addition_ also use the clipboard.  If
that's the intent of this text, then it seems to be in contradiction
with the new default of x-select-enable-primary.

OTTH (On The Third Hand), mouse-2 is one way of pasting (yanking) text
that was cut (killed) elsewhere.  And the new binding of mouse-2 to
mouse-yank-primary _does_ insert text from the primary selection,
albeit by a different way.  IOW, mouse-2 works _against_ the value of
x-select-enable-primary.  It also seems to be in contradiction with
the NEWS entry, in that it doesn't access the clipboard (unless I'm
missing something).

How to reconcile these apparent contradictions?  What exactly is the
role of x-select-enable-primary, if Emacs does not behave according to
its value and its advertised doc string?

Do we still want to have kill/yank and cut/paste be largely synonyms?
If so, they are now a tad less synonyms, so it seems, as at least one
commonly used command does paste, but does not yank.

Please also note that x-select-enable-primary exists only on X, but
the changes we are discussing affect all builds, which just adds to
confusion on those builds that do not use X.  See below for one such

> We could change mouse-yank-primary so that it calls yank if no primary
> selection exists.  But maybe that is too confusing.

This is directly relevant to the issue at (my) hand: how to restore
the expected behavior of selections on Windows.  If it is okay to call
`yank' when there's no primary selection, then that's one way of
fixing the bug on Windows.  But then note that `yank' does not only
insert text, it also does other non-trivial things to the kill ring
etc.; so if the primary selection _does_ exist, all those things won't
be done.  This is unlike the old code, which accessed the selection
from inside `yank', and then treated it in the same way as if it came
from the kill ring.

An alternative way of fixing the bug on Windows would be to modify the
Windows implementation of x-get-selection to get the text from the
clipboard if the (emulated) primary selection does not exist.

Which of these ways is the best one, depends on clearing up the above
confusions.  You say "maybe [calling yank] is too confusing" -- what
kind of confusion do you envision here?

One other issue we should consider IMO is what is the semantics of
mouse-2 in sessions that support the mouse, but cannot access
selections.  One such example is a TTY with a GPM mouse.  I don't have
access to such a build of Emacs, but I'm quite sure mouse-2 there will
either do nothing or signal an error.  That's hardly a good thing,
because previously it would yank from the kill ring.

Thanks in advance for helping me become less confused.

reply via email to

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