bug#23571: 25.1.50; Click-mouse-1 = Drag-mouse-1 in Gnus Article buffer

[Stephen Berman <stephen.berman@gmx.net>]

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

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Thu, 26 May 2016 18:09:56 +0200
>> 
>> On Wed, 18 May 2016 15:27:23 +0200 Stephen Berman <stephen.berman@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@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?

I experimented a bit.  The problem disappears by not making
widget-keymap the parent of gnus-article-mode-map but instead putting
the widget bindings directly into gnus-article-mode-map, reverting the
problematic bindings:

diff --git a/lisp/gnus/gnus-art.el b/lisp/gnus/gnus-art.el
index c103e1c..9a64102 100644
--- a/lisp/gnus/gnus-art.el
+++ b/lisp/gnus/gnus-art.el
@@ -4363,9 +4363,21 @@ article-verify-cancel-lock
 
 (put 'gnus-article-mode 'mode-class 'special)
 
-(set-keymap-parent gnus-article-mode-map widget-keymap)
+;; (set-keymap-parent gnus-article-mode-map widget-keymap)
+(put 'widget-backward :advertised-binding [(shift tab)])
 
 (gnus-define-keys gnus-article-mode-map
+  ;; Bindings from widget-keymap (but using down-mouse-{1,2}
+  ;; instead mouse-{1,2} to avoid bug#23571).
+  "\t" widget-forward
+  "\e\t" widget-backward
+  [(shift tab)] widget-backward
+  [backtab] widget-backward
+  [down-mouse-2] widget-button-click
+  [down-mouse-1] widget-button-click
+    ;; The following definition needs to avoid using escape sequences that
+    ;; might get converted to ^M when building loaddefs.el
+  [(control ?m)] widget-button-press
+
   " " gnus-article-goto-next-page
   [?\S-\ ] gnus-article-goto-prev-page
   "\177" gnus-article-goto-prev-page

I also tried keeping widget-keymap as the parent and just changing the
problematic bindings:

diff --git a/lisp/gnus/gnus-art.el b/lisp/gnus/gnus-art.el
index c103e1c..6b25fcd 100644
--- a/lisp/gnus/gnus-art.el
+++ b/lisp/gnus/gnus-art.el
@@ -4366,6 +4366,13 @@ article-verify-cancel-lock
 (set-keymap-parent gnus-article-mode-map widget-keymap)
 
 (gnus-define-keys gnus-article-mode-map
+  ;; Suppress these two bindings from widget-keymap...
+  [mouse-2] ignore
+  [mouse-1] ignore
+  ;; ... and use down-mouse-{1,2} instead to avoid bug#23571.
+  [down-mouse-2] widget-button-click
+  [down-mouse-1] widget-button-click
+
   " " gnus-article-goto-next-page
   [?\S-\ ] gnus-article-goto-prev-page
   "\177" gnus-article-goto-prev-page

This also fixes the problem I observed with mouse-1; however, clicking
on an email address with mouse-1 not only correctly opens a message
buffer to compose an email to that address, but also incorrectly inserts
the most recent item in the desktop clipboard (or primary selection?) at
point in that buffer.  In contrast, mouse-2 DTRT here.

Steve Berman