bug#24563: kill-region fails while dragging a selection

bug#24563: kill-region fails while dragging a selection

[Phil Ruffwind]

Emacs 25.1 seems to have changed the behavior of doing kill-region (C-w)
while dragging a selection in GUI mode.  Here are the steps to
reproduce:

 1. Run Emacs in GUI mode via: emacs -Q
 2. Type: M-x set-variable mark-even-if-inactive nil
 3. Open a file containing some text.
 4. Make a selection using the mouse, but do NOT release the mouse
    button.
 5. Type: C-w.

In Emacs 24.5, this would initially do nothing, but pressing C-w a
second time will kill the selected region correctly.

In Emacs 25.1, this fails with "The mark is not active now" and
deselects the region.

Had I turned mark-even-if-inactive back on, it would cause the
previously selected region to be killed instead, which can lead to lots
of accidental killing.

Naturally, one wouldn't do this on purpose: one should release the drag
before doing C-w, but it's very easy to accidentally overlap the two
operations when done in haste.

---

In GNU Emacs 25.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.20.9)
 of 2016-09-18 built on juergen
Windowing system distributor 'The X.Org Foundation', version
11.0.11804000
System Description:     Arch Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe
 -fstack-protector-strong' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cus-edit
wid-edit cus-start cus-load thingatpt help-fns help-mode easymenu
cl-loaddefs pcase cl-lib time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

bug#24563: kill-region fails while dragging a selection

[Eli Zaretskii]

> From: Phil Ruffwind <rf@rufflewind.com>
> Date: Wed, 28 Sep 2016 14:30:44 -0400
> 
> Emacs 25.1 seems to have changed the behavior of doing kill-region (C-w)
> while dragging a selection in GUI mode.  Here are the steps to
> reproduce:
> 
>  1. Run Emacs in GUI mode via: emacs -Q
>  2. Type: M-x set-variable mark-even-if-inactive nil
>  3. Open a file containing some text.
>  4. Make a selection using the mouse, but do NOT release the mouse
>     button.
>  5. Type: C-w.
> 
> In Emacs 24.5, this would initially do nothing, but pressing C-w a
> second time will kill the selected region correctly.
> 
> In Emacs 25.1, this fails with "The mark is not active now" and
> deselects the region.

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?

Thanks for reporting this.

bug#24563: kill-region fails while dragging a selection

[Phil Ruffwind]

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

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

This makes killing text selected by the mouse unnecessarily fragile.

Thanks.

bug#24563: kill-region fails while dragging a selection

[Eli Zaretskii]

> From: Phil Ruffwind <rf@rufflewind.com>
> Cc: 24563@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.

bug#24563: kill-region fails while dragging a selection

[Noam Postavsky]

tags 24563 notabug wontfix
close 24563
quit

Eli Zaretskii <eliz@gnu.org> writes:

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

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

Seems there is nothing more to say.