GNU bug report logs - #6689
24.0.50; No primary selection

Previous Next

Full log

Message #71 received at 6689-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 6689-done <at> debbugs.gnu.org, cyd <at> stupidchicken.com
Subject: Re: bug#6689: 24.0.50; No primary selection
Date: Sat, 14 Aug 2010 19:32:24 +0300

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <cyd <at> stupidchicken.com>, <6689-done <at> debbugs.gnu.org>
> Date: Sat, 14 Aug 2010 09:05:36 -0700
> 
> > This bug should now be fixed (revno 101080).
> 
> Thanks.
> 
> > If the cure turns out to be worse than the disease, please reopen this
> > bug.  If, OTOH, there are other issues with selections and cut/paste
> > on Windows due to the latest changes, please submit separate bug
> > reports.
> 
> It's hard for me to know what behavior change is a bug and what is intentional,
> and I might not be sure whether some behavior change is part of this bug or
> another (new) one.

Let's define "part of this bug" as any abnormal effects of clicking
mouse-2 when a selection exists either in the current session of Emacs
or in another application (via the clipboard).  The "normal effect" is
having the selected text pasted at mouse click location.

Please note that the way I fixed the bug is that the text from the
clipboard should be pasted in preference to the text selected in the
current session.  This particular behavior was my decision, so if it
somehow interferes with your expectations, please also reopen this
bug.

> But one way or the other I'll report what I find if I feel it isn't
> right.

I don't doubt that.

> I've tried to follow some of the discusson on emacs-devel, but it is not clear
> to me what it might mean in practice. And I know that the current behavior
> cannot be judged as the intended one, as others have mentioned (wait until the
> wrinkles are ironed out). So I'll wait to see what develops.
> 
> I think (on Windows) the past interaction between mouse and keyboard and between
> clipboard and kill ring was good. But I will wait to see what (intended) changes
> are in store. At the moment it is not clear (to me) what the final behavior will
> be.

The issue that I left open is indeed what, if anything, should happen
with the clipboard when the user selects text in Emacs without killing
it.  I think this should be decided only _after_ a similar decision is
made regarding Emacs on X.  Right now, the behavior on X in this
regard is messy, to say the least, and it's not clear at all what we
want, let alone how to get there.

Since mouse-drag-copy-region was changed to default to nil, Emacs on
Windows should not currently set the clipboard when text is just
selected, but not killed.  Whether this is correct behavior depends on
what we decide for X and what other Windows users say.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.