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

From: Eli Zaretskii <[email-masked]>
Date: Tue, 07 Jun 2016 18:03:53 +0300

> From: Stephen Berman <[email-masked]>
> Cc: [email-masked]
> Date: Tue, 07 Jun 2016 11:05:29 +0200
> 
> On Tue, 07 Jun 2016 05:31:34 +0300 Eli Zaretskii <[email-masked]> wrote:
> 
> >> From: Stephen Berman <[email-masked]>
> >> Cc: [email-masked]
> >> Date: Mon, 06 Jun 2016 21:38:02 +0200
> >> 
> >> >> 72166f2f3dba18f1217c666574032f5a0351ed65 is the first bad commit
> >> >> commit 72166f2f3dba18f1217c666574032f5a0351ed65
> >> >> Author: Martin Rudalics <[email-masked]>
> >> >> 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?
> 
> I went through those two bug reports and I cannot reproduce the
> problematic cases (bug#19185: mouse-2 running mouse-yank-primary in a
> Gnus Article buffer; bug#20398: mouse-1 raising error "No selection is
> available" on links in a Customize buffer) with -Q in current emacs-25,
> which does not include the above commit.  And when I revert that commit
> in master I also cannot reproduce those problems.  So it's not clear to
> me what that commit is trying to fix.

I hope Martin will be able to help us answer that question.