GNU bug report logs - #23707
25.0.94; Regression in mouse-set-region

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23707 in the body.
You can then email your comments to 23707 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Alex <agrambot <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.94; Regression in mouse-set-region
Date: Mon, 06 Jun 2016 11:51:14 -0600

When using the mouse to set a region outside of the current window, the
region is now created improperly. There are two basic cases:

a) dragging the mouse and ending on or outside the Emacs frame causes no
region to be created

Steps to reproduce:

1. emacs -Q
2. In the scratch buffer with <mouse-1>, drag the region and end off in
the menu-bar area.
3. The region is not created.

b) dragging the mouse and ending in another Emacs window causes a region
to be created between the starting point and the point corresponding to
the ending point *in the other buffer*.

1. emacs -Q
2. C-x 2
3. C-x 0
4. In the bottom scratch window, drag with your mouse and end somewhere
in the scratch message int he top window
5. The region is created, but ends prematurely at whatever point you
ended at in the top window.


Emacs 24.5 had the correct behaviour of creating a region between the
starting point and one of the ends of the buffer when dragging outside
of the current window.

In GNU Emacs 25.0.94.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
 of 2016-05-17 built on lylat
Windowing system distributor 'Fedora Project', version 11.0.11803000
Configured using:
 'configure --with-gif=no'

Configured features:
XPM JPEG TIFF PNG SOUND DBUS GSETTINGS NOTIFY FREETYPE XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LC_CTYPE: en_CA.utf8
  value of $LANG: en_CA.utf8
  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 cl-extra
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)

Memory information:
((conses 16 88650 8250)
 (symbols 48 19654 1)
 (miscs 40 73 288)
 (strings 32 14307 4665)
 (string-bytes 1 411990)
 (vectors 16 11811)
 (vector-slots 8 429433 6340)
 (floats 8 168 88)
 (intervals 56 243 0)
 (buffers 976 12)
 (heap 1024 46192 1533))

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

From: martin rudalics <rudalics <at> gmx.at>
To: Alex <agrambot <at> gmail.com>, 23707 <at> debbugs.gnu.org
Subject: Re: bug#23707: 25.0.94; Regression in mouse-set-region
Date: Tue, 07 Jun 2016 11:10:04 +0200

[Message part 1 (text/plain, inline)]

> When using the mouse to set a region outside of the current window, the
> region is now created improperly. There are two basic cases:
>
> a) dragging the mouse and ending on or outside the Emacs frame causes no
> region to be created
>
> Steps to reproduce:
>
> 1. emacs -Q
> 2. In the scratch buffer with <mouse-1>, drag the region and end off in
> the menu-bar area.
> 3. The region is not created.
>
> b) dragging the mouse and ending in another Emacs window causes a region
> to be created between the starting point and the point corresponding to
> the ending point *in the other buffer*.
>
> 1. emacs -Q
> 2. C-x 2
> 3. C-x 0
> 4. In the bottom scratch window, drag with your mouse and end somewhere
> in the scratch message int he top window
> 5. The region is created, but ends prematurely at whatever point you
> ended at in the top window.
>
>
> Emacs 24.5 had the correct behaviour of creating a region between the
> starting point and one of the ends of the buffer when dragging outside
> of the current window.
>
> In GNU Emacs 25.0.94.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
>   of 2016-05-17 built on lylat
> Windowing system distributor 'Fedora Project', version 11.0.11803000
> Configured using:
>   'configure --with-gif=no'

Both scenarios are easily reproducible on Windows.  Would the attached
patch fix it for you?

Thanks, martin

[mouse.diff (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 23707 <at> debbugs.gnu.org, agrambot <at> gmail.com
Subject: Re: bug#23707: 25.0.94; Regression in mouse-set-region
Date: Tue, 07 Jun 2016 18:06:00 +0300

> Date: Tue, 07 Jun 2016 11:10:04 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> 
> Both scenarios are easily reproducible on Windows.  Would the attached
> patch fix it for you?

I arrived at the same fix.  Which made me wonder: why not use the
window-point always, and ignore event-end?  Will that ever be wrong?
If not, perhaps we should do that on master.

Thanks.

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

From: Alex <agrambot <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 23707 <at> debbugs.gnu.org
Subject: Re: bug#23707: 25.0.94; Regression in mouse-set-region
Date: Tue, 07 Jun 2016 11:06:41 -0600

martin rudalics <rudalics <at> gmx.at> writes:

> Both scenarios are easily reproducible on Windows.  Would the attached
> patch fix it for you?
>
> Thanks, martin

For some reason I had to recompile Emacs (not just mouse.el) for the
patch to work, but after that it now works in both cases.

Thank you,

Alex

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 23707 <at> debbugs.gnu.org, rudalics <at> gmx.at
Subject: Re: bug#23707: 25.0.94; Regression in mouse-set-region
Date: Tue, 07 Jun 2016 20:19:52 +0300

> From: Alex <agrambot <at> gmail.com>
> Date: Tue, 07 Jun 2016 11:06:41 -0600
> Cc: 23707 <at> debbugs.gnu.org
> 
> martin rudalics <rudalics <at> gmx.at> writes:
> 
> > Both scenarios are easily reproducible on Windows.  Would the attached
> > patch fix it for you?
> >
> > Thanks, martin
> 
> For some reason I had to recompile Emacs (not just mouse.el) for the
> patch to work

That's because mouse.el is preloaded, see loadup.el.  IOW, this is
normal.

Thanks for testing.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23707 <at> debbugs.gnu.org, agrambot <at> gmail.com
Subject: Re: bug#23707: 25.0.94; Regression in mouse-set-region
Date: Wed, 08 Jun 2016 08:33:58 +0200

> I arrived at the same fix.  Which made me wonder: why not use the
> window-point always, and ignore event-end?  Will that ever be wrong?
> If not, perhaps we should do that on master.

I'll try to put a comparison into my master together with a ding when
the values of ‘event-end’ and ‘window-point’ do not coincide for the
"same window" case.  But I rarely use the mouse to mark text ...

Meanwhile we should apply the fix to the release branch, I suppose?

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Alex <agrambot <at> gmail.com>
Cc: 23707 <at> debbugs.gnu.org
Subject: Re: bug#23707: 25.0.94; Regression in mouse-set-region
Date: Wed, 08 Jun 2016 08:34:10 +0200

> For some reason I had to recompile Emacs (not just mouse.el) for the
> patch to work, but after that it now works in both cases.

Eli explained why you had to do that.  Alternatively, you can put the
function that changed into your .emacs.  This way you can avoid
recompiling and save some time when you have the premonition that a
couple of iterations will be needed to get that function right.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 23707 <at> debbugs.gnu.org, agrambot <at> gmail.com
Subject: Re: bug#23707: 25.0.94; Regression in mouse-set-region
Date: Wed, 08 Jun 2016 19:42:23 +0300

> Date: Wed, 08 Jun 2016 08:33:58 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: agrambot <at> gmail.com, 23707 <at> debbugs.gnu.org
> 
> Meanwhile we should apply the fix to the release branch, I suppose?

Yes, thanks.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23707-done <at> debbugs.gnu.org, agrambot <at> gmail.com
Subject: Re: bug#23707: 25.0.94; Regression in mouse-set-region
Date: Thu, 09 Jun 2016 10:38:12 +0200

>> Meanwhile we should apply the fix to the release branch, I suppose?
>
> Yes, thanks.

Done now.  Bug closed.

Thanks (in particular for the fine report), martin

Previous Next

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