I took a look at this bug and it turned out to be really tricky. So I did
all the research I could, to try to find a good fix.
Because the widget-button-click code was written before the addition of
mouse-1-click-follows-link, there is some work to be done to adapt it. Even
though there were some attempts , they weren't enough.
The attached patch tries to fix this bug, while trying to not change too much
of the code of the widget library. It introduces a keymap for the link widgets,
and only binds mouse-2 events. Since widget-button-click isn't changed, it
has to bind down-mouse-2 too. In this fix, I also have been careful to not
reintroduce bugs that have come up by changing the keybindings in the
widget-keymap, such as here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23571
I investigated the emacs sources, and have noticed that this patch could cause
problems with three pieces of code:
1) recentf.el: Because of Bug#22434, puts a nil :follow-link property to the
link widget. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22434
The patch would make that mouse-1 isn't translated to mouse-2, but since this
was a workaround, changing this code would be OK, I think. Without
overriding :follow-link, I have checked that recentf.el works like it should,
with this patch applied.
2) epa.el: Typing M-x epa-encrypt-file brings up a *Keys* buffer. This buffer
has clickable text: [Cancel] and [OK]. The epa code create this as a link
widget, and when mouse-1-click-follows-link is nil, this text becomes not
responsive with mouse-1. I'd say this are more buttons than links,
so a fix for it (if it is considered it needs fixing) would be to turn them into
3) mh-mime.el: I have never used MH-E. But there is some code in mh-mime.el
that creates a link widget, with an action mh-widget-press-button, and it
looks like it has a keymap of its own. I don't know if the behavior could
I haven't found any other code in the Emacs sources that could have problems.
And fixing this would make code that depends on the link widgets to behave as
expected, when mouse-1-click-follows-link is customized to a nil value. So I
think it would be good to fix this.