GNU bug report logs - #24563
kill-region fails while dragging a selection

Previous Next

Package: emacs;

Reported by: Phil Ruffwind <rf <at> rufflewind.com>

Date: Wed, 28 Sep 2016 23:32:01 UTC

Severity: normal

Tags: notabug, wontfix

Done: Noam Postavsky <npostavs <at> users.sourceforge.net>

Bug is archived. No further changes may be made.

Full log


Message #14 received at 24563 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Ruffwind <rf <at> rufflewind.com>
Cc: 24563 <at> debbugs.gnu.org
Subject: Re: bug#24563: kill-region fails while dragging a selection
Date: Sat, 01 Oct 2016 10:55:23 +0300
> From: Phil Ruffwind <rf <at> rufflewind.com>
> Cc: 24563 <at> debbugs.gnu.org
> Date: Fri, 30 Sep 2016 17:29:01 -0400
> 
> > Why is this a bug?  Neither of the two behaviors is AFAIK documented,
> > so either could be correct.  I agree that the behavior changed, most
> > probably because both the implementation of region highlight and the
> > binding of commands to the mouse have changed in Emacs 25.1.  But is
> > there a reason not to get along with the new behavior?
> 
> It's easy to mistakenly hit C-w just before (instead of after) the mouse
> button is released, so the behavior of this scenario affects the UX for
> killing text quickly with the aid of the mouse.

Since it's a user error, signaling an error is TRT, IMO.  And
recovering from the error is easy: "C-x C-x", then "C-w".

> The old behavior mostly worked as expected.  The new behavior does
> something totally different:
> 
> - If mark-even-if-inactive is nil, then it will fail but also deselect
> the region, so the user has to start over.
> 
> - If mark-even-if-inactive is non-nil, then it will succeed but will
> mostly likely kill the wrong region (the previously marked region).

What Emacs does when the user makes an error is not well defined.  The
above just shows that we changed one undefined behavior for another.

> This makes killing text selected by the mouse unnecessarily fragile.

I don't think it's right to call this fragile, as we are talking about
reaction to a clear user error.  It is IMO unreasonable to expect
Emacs development to proceed with 100% bug-compatibility to previous
undefined behaviors.

So I think this is not a bug at all, but a reasonable consequence of
Emacs development.  I understand that it gets in the way with your
muscle memory, but I think the way to overcome that is by changing
your customizations and/or habits.  Sorry, I see no other way.




This bug report was last modified 7 years and 178 days ago.

Previous Next


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