GNU bug report logs -
#15682
24.3.50; `:link' in `defgroup' does not respect `mouse-1-click-follows-link'
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Tue, 22 Oct 2013 15:29:02 UTC
Severity: minor
Tags: fixed
Merged with 52
Found in version 24.3.50
Fixed in version 27.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15682 in the body.
You can then email your comments to 15682 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15682
; Package
emacs
.
(Tue, 22 Oct 2013 15:29:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Drew Adams <drew.adams <at> oracle.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 22 Oct 2013 15:29:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
emacs -Q
In *scratch*, evaluate this:
(defgroup foo nil
"..." :prefix "foo-" :group 'editing
:link '(url-link "http://www.emacswiki.org/"))
(defcustom foobar t "..." :type 'boolean :group 'foo)
M-x set-variable mouse-1-click-follows-link nil
M-x customize-option foobar
Click the link `http://www.emacswiki.org/' using `mouse-1'. The link is
followed - it should not be followed.
Note that `mouse-on-link-p' returns `t' for positions on this link, and
such positions have face `custom-link', property `follow-link' with
value `mouse-face', and property `mouse-face' with a face value, all of
which show further that the behavior violates the mandate of
`mouse-1-click-follows-link'.
Quite annoying. Emacs should not overrule user settings like this.
This is not a regression: it has been broken from the outset (broken in
all Emacs versions that support `:link').
In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
of 2013-10-19 on LEG570
Bzr revision: 114715 rgm <at> gnu.org-20131019023520-s8mwtib7xcx9e05w
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'
Merged 52 15682.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 08 Feb 2014 03:46:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15682
; Package
emacs
.
(Wed, 27 Apr 2016 16:10:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 15682 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> (defgroup foo nil
> "..." :prefix "foo-" :group 'editing
> :link '(url-link "http://www.emacswiki.org/"))
>
> (defcustom foobar t "..." :type 'boolean :group 'foo)
>
> M-x set-variable mouse-1-click-follows-link nil
> M-x customize-option foobar
>
> Click the link `http://www.emacswiki.org/' using `mouse-1'. The link is
> followed - it should not be followed.
>
> Note that `mouse-on-link-p' returns `t' for positions on this link, and
> such positions have face `custom-link', property `follow-link' with
> value `mouse-face', and property `mouse-face' with a face value, all of
> which show further that the behavior violates the mandate of
> `mouse-1-click-follows-link'.
I've had another peek at this, but the main problem is that I don't
quite understand why the Widget code is so... complicated. Why does it
do all the stuff below? I mean, no other modes that react to mouse
clicks need to ... do all that...
(defun widget-button-click (event)
"Invoke the button that the mouse is pointing at."
(interactive "e")
(if (widget-event-point event)
(let* ((oevent event)
(mouse-1 (memq (event-basic-type event) '(mouse-1 down-mouse-1)))
(pos (widget-event-point event))
(start (event-start event))
(button (get-char-property
pos 'button (and (windowp (posn-window start))
(window-buffer (posn-window start)))))
newpoint)
(when (or (null button)
(catch 'button-press-cancelled
;; Mouse click on a widget button. Do the following
;; in a save-excursion so that the click on the button
;; doesn't change point.
(save-selected-window
(select-window (posn-window (event-start event)))
(save-excursion
(goto-char (posn-point (event-start event)))
(let* ((overlay (widget-get button :button-overlay))
(pressed-face (or (widget-get button :pressed-face)
widget-button-pressed-face))
(face (overlay-get overlay 'face))
(mouse-face (overlay-get overlay 'mouse-face)))
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15682
; Package
emacs
.
(Wed, 27 Apr 2016 16:25:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 15682 <at> debbugs.gnu.org (full text, mbox):
> I've had another peek at this,
Thanks for looking into it.
> but the main problem is that I don't quite understand why the
> Widget code is so... complicated.
I sympathize, and I agree that is difficult to fathom.
Can't help with the understanding, however.
> Why does it do all the stuff below? I mean, no other modes
> that react to mouse clicks need to ... do all that...
Dunno. But just because the code can be difficult to follow
is not a reason to assume that it does unnecessary things, in
general. The widget code that I've been able to follow does
DTRT, generally (AFAICT).
I doubt that anyone left understands the widget code well.
Maybe you can find Per Abrahamsen and get him to take a look?
The URLs for him listed here are dead, but maybe looking here
would be a start: https://www.emacswiki.org/emacs/PerAbrahamsen.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15682
; Package
emacs
.
(Wed, 27 Apr 2016 16:54:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 15682 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> Dunno. But just because the code can be difficult to follow
> is not a reason to assume that it does unnecessary things, in
> general. The widget code that I've been able to follow does
> DTRT, generally (AFAICT).
It does, but the logic is very hard to follow. Custom/widget works by
inserting text into the buffer, and then "converting" it to a widget, or
by creating a widget and then inserting it. And it does it all with
overlays, and seems like it's created its own event handling distinct
from the normal Emacs event handler, sort of.
There are, of course, historical reasons for this. Per wrote Widget in
the mid 90s when many of these issues hadn't been resolved, and it
worked across many Emacs versions.
I kinda think it might be time to consider doing a rewrite from scratch
using modern Emacs features, and then things like this bug report would
start working automatically.
How big a task would this be? I mean, of course we'd keep compatibility
(the defcustom language is fine), but just rewrite the UI `M-x
customize' bits... Hm...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15682
; Package
emacs
.
(Wed, 27 Apr 2016 17:19:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 15682 <at> debbugs.gnu.org (full text, mbox):
> I kinda think it might be time to consider doing a rewrite from scratch
> using modern Emacs features, and then things like this bug report would
> start working automatically.
>
> How big a task would this be? I mean, of course we'd keep compatibility
> (the defcustom language is fine), but just rewrite the UI `M-x
> customize' bits... Hm...
I can't speak to this, sorry. I'll just mention that I think:
(1) it could be a large undertaking and (2) there is existing
code out there that depends on or enhances cus*.el and wid*.el
code.
Personally, I would prefer that we live with it, and try to
improve it incrementally, rather than opting for a rewrite or
replacement. I'd like to see a resident Emacs expert on wid*
and cus*, rather than someone who doesn't master it just trying
for a replacement.
(Yes, I'm conservative wrt this stuff. Emacs is one of the
few things I'm conservative about. ;-))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15682
; Package
emacs
.
(Fri, 23 Aug 2019 20:43:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 15682 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 [1], 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
push-button widgets.
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
change here.
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.
[1] https://lists.gnu.org/archive/html/emacs-devel/2008-03/msg01312.html
[Message part 2 (text/html, inline)]
[0001-Make-link-widgets-obey-mouse-1-click-follows-link.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15682
; Package
emacs
.
(Sun, 25 Aug 2019 05:48:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 15682 <at> debbugs.gnu.org (full text, mbox):
Mauro Aranda <maurooaranda <at> gmail.com> writes:
> 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 think this makes sense.
> I investigated the emacs sources, and have noticed that this patch could cause
> problems with three pieces of code:
Would it be possible for you to come up with patches for fixing these
three pieces, too? And then we could apply all four patches at the same
time and not break anything.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15682
; Package
emacs
.
(Sun, 25 Aug 2019 15:08:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 15682 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>
>> I investigated the emacs sources, and have noticed that this patch could
cause
>> problems with three pieces of code:
>
> Would it be possible for you to come up with patches for fixing these
> three pieces, too? And then we could apply all four patches at the same
> time and not break anything.
Sure. I attach 3 patches. The same one I attached in my previous
message, one patch for recentf.el and one patch for epa.el.
I tried MH-E, to test the mh-mime.el code, and doesn't seem to misbehave
with the change in wid-edit.el, so I didn't touch it.
Best regards,
Mauro.
[Message part 2 (text/html, inline)]
[0001-Make-link-widgets-obey-mouse-1-click-follows-link.patch (text/x-patch, attachment)]
[0001-Adapt-recentf.el-to-the-change-in-the-Widget-Library.patch (text/x-patch, attachment)]
[0001-Create-push-button-widgets-instead-of-links-in-epa-K.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15682
; Package
emacs
.
(Sun, 25 Aug 2019 16:20:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 15682 <at> debbugs.gnu.org (full text, mbox):
What happened to the bug # in the Subject line?
Please restore it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15682
; Package
emacs
.
(Sun, 25 Aug 2019 16:24:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 15682 <at> debbugs.gnu.org (full text, mbox):
> What happened to the bug # in the Subject line?
> Please restore it.
Hm. I see it got restored by my reply.
Why was it missing from Mauro's and Lars's
mails? E.g.:
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Sent: Saturday, August 24, 2019 10:47 PM
> To: Mauro Aranda <maurooaranda <at> gmail.com>
> Cc: 15682 <at> debbugs.gnu.org; Drew Adams <drew.adams <at> oracle.com>
> Subject: Re: 24.3.50; `:link' in `defgroup' does not respect `mouse-1-
> click-follows-link'
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15682
; Package
emacs
.
(Sun, 25 Aug 2019 16:42:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 15682 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 25 Aug 2019 09:22:54 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 15682 <at> debbugs.gnu.org
>
> > What happened to the bug # in the Subject line?
> > Please restore it.
>
> Hm. I see it got restored by my reply.
> Why was it missing from Mauro's and Lars's
> mails? E.g.:
>
> > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > Sent: Saturday, August 24, 2019 10:47 PM
> > To: Mauro Aranda <maurooaranda <at> gmail.com>
> > Cc: 15682 <at> debbugs.gnu.org; Drew Adams <drew.adams <at> oracle.com>
> > Subject: Re: 24.3.50; `:link' in `defgroup' does not respect `mouse-1-
> > click-follows-link'
You need to get a better email client.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15682
; Package
emacs
.
(Sun, 25 Aug 2019 16:52:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 15682 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
>> What happened to the bug # in the Subject line?
>> Please restore it.
>
> Hm. I see it got restored by my reply.
> Why was it missing from Mauro's and Lars's
> mails? E.g.:
I guess Mauro just copied the subject from
https://debbugs.gnu.org/15682#5, which doesn't include the bug number
(because it shows mail as it was originally sent, before the bug number
was assigned).
When someone sends a message without the bug number to a
nnnnn <at> debbugs.gnu.org address, the bug list mail server adds the bug
number back; but if you're on Cc, then you'll get the message directly
from the sender (i.e., not from the server, and so you won't see the
number added back in. I think you would *also* get the message from the
server with the bug number, but depending on your mail setup, it might
get hidden/deleted as a duplicate).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15682
; Package
emacs
.
(Sun, 25 Aug 2019 16:59:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 15682 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Noam Postavsky <npostavs <at> gmail.com> writes:
> Drew Adams <drew.adams <at> oracle.com> writes:
>
>>> What happened to the bug # in the Subject line?
>>> Please restore it.
>>
>> Hm. I see it got restored by my reply.
>> Why was it missing from Mauro's and Lars's
>> mails? E.g.:
>
> I guess Mauro just copied the subject from
> https://debbugs.gnu.org/15682#5, which doesn't include the bug number
> (because it shows mail as it was originally sent, before the bug number
> was assigned).
>
That might be what happened.
Sorry for the inconvenience.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15682
; Package
emacs
.
(Tue, 27 Aug 2019 06:43:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 15682 <at> debbugs.gnu.org (full text, mbox):
Mauro Aranda <maurooaranda <at> gmail.com> writes:
> Sure. I attach 3 patches. The same one I attached in my previous
> message, one patch for recentf.el and one patch for epa.el.
>
> I tried MH-E, to test the mh-mime.el code, and doesn't seem to misbehave
> with the change in wid-edit.el, so I didn't touch it.
Thanks; I've now applied all three patches to the Emacs trunk.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Tue, 27 Aug 2019 06:43:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 27.1, send any further explanations to
15682 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Tue, 27 Aug 2019 06:43:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 24 Sep 2019 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 56 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.