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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 23571 <at> debbugs.gnu.org
Subject: Re: bug#23571: 25.1.50;
 Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer
Date: Tue, 07 Jun 2016 05:31:34 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 23571 <at> debbugs.gnu.org
> Date: Mon, 06 Jun 2016 21:38:02 +0200
> 
> >> 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.

How do you do that without reintroducing the bug referenced in the
above commit's log message?

Previous Next

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