GNU bug report logs -
#60423
29.0.60; goto-address and shr/textsec don't play nicely together
Previous Next
Full log
View this message in rfc822 format
Eli Zaretskii wrote:
> > From: Mike Kupfer <kupfer <at> rawbw.com>
[...]
> > Stefan Monnier wrote:
[...]
> > > Maybe it should check for the presence of `help-echo and (follow-link
> > > or keymap)`? And make sure the those properties cover exactly the same
> > > chunk of text?
> >
> > As far as covering the same chunk of text, I'll need to play with this
> > some more to see what works. shr-tag-a inserts a warning emoji with a
> > help-echo property, which goto-address somehow manages to clobber. That
> > warning emoji is not something goto-address would normally be looking
> > for.
>
> Ping! How can we make some progress with this bug report?
I did figure out why goto-address is clobbering the help-echo property
on the warning emoji. goto-address uses goto-address-url-regexp to
identify URLs. shr puts the emoji immediately after the suspicious URL,
and apparently the regexp includes the emoji as part of the URL.
https://badurl.com⚠️
I haven't completely reverse-engineered the regexp. I see that it's
built from a list of URI schemes and thing-at-point-url-path-regexp.
Maybe thing-at-point-url-path-regexp needs to be pickier? But I don't
understand how things should work in light of internationalized URLs.
I've thought about having goto-address bail out if there are any
conflicting properties in the range that it wants to overlay, but I
haven't had time to prototype it to see how well that works.
I suppose another possibility would be to move the warning emoji: put it
in front of the suspicious URL, rather than after the URL.
WDYT?
mike
This bug report was last modified 225 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.