GNU bug report logs - #23571
25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer

Previous Next

Full log

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23571 <at> debbugs.gnu.org
Subject: Re: bug#23571: 25.1.50;
 Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer
Date: Mon, 06 Jun 2016 21:38:02 +0200

On Thu, 26 May 2016 19:37:52 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Date: Thu, 26 May 2016 18:09:56 +0200
>> 
>> On Wed, 18 May 2016 15:27:23 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>> 
>> > Clicking mouse-1 in a Gnus Article buffer, then releasing it and moving
>> > the mouse (without holding down a mouse key) highlights a region, just
>> > as when the mouse is dragged with mouse-1 held down.  To reproduce:
>> >
>> > 0. emacs -Q
>> > 1. M-x gnus, type `y' at the prompt, then type `B RET news.gmane.org RET
>> >    1 RET' to open the most recent article in gmane.announce on the
>> >    news.gmane.org server.
>> > 2. Click anywhere in the Article buffer (except on the texts following
>> >    the From: and To: headers, which are buttons) with mouse-1, release
>> >    mouse-1, move the mouse.
>> > => A region is highlighted.
>> >
>> > Subsequently clicking and releasing mouse-1 does not deactivate the
>> > mark (but clicking with mouse-2 or mouse-3 does).
>> >
>> > I have not observed this behavior anywhere besides Gnus Article buffers.
>> >
>> > This happens in master but not in emacs-25.  It happens at least since
>> > commit 62d7acae7405732268713006d839a5c3507b9482, which was my first
>> > build from master after a long pause, so I don't know when this behavior
>> > first appeared (I didn't save any earlier builds from master, which were
>> > from many months before, but I'm sure they didn't show this behavior).
>> 
>> Git bisect says:
>> 
>> 72166f2f3dba18f1217c666574032f5a0351ed65 is the first bad commit
>> commit 72166f2f3dba18f1217c666574032f5a0351ed65
>> Author: Martin Rudalics <rudalics <at> gmx.at>
>> Date:   Tue May 3 08:38:49 2016 +0200
>> 
>>     Bind `widget-button-click' to mouse-1/-2 instead of down-mouse-1/-2
>>     
>>     * lisp/wid-edit.el (widget-keymap): Bind `widget-button-click'
>>     to mouse-1/-2 instead of down-mouse-1/-2.  Suggested by Stefan
>>     Monnier.  (Bug#19185, Bug#20398)
>
> So I guess Gnus needs to do something to countermand the low-level
> change, right?

It turns out it's not just Gnus Article buffers (as presciently
suggested by the title of bug#23653, which I merged with this one): in
fact, the same problem appears to happen in all packages in which
buffers use widget-keymap; there are quite a few of these, as rgrepping
for widget-keymap on the lisp directory shows, and in all that I tried
(cus-edit, wid-browse, recentf, printing, secrets, image-dired,
todo-mode) the problem with mouse-1 occurred.  So I think the fix should
be in widget-button-click, or somewhere at that level, and not in all of
its users.

Steve Berman

Previous Next

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