bug#60423: 29.0.60; goto-address and shr/textsec don't play nicely together

[Mike Kupfer <kupfer@rawbw.com>]

Eli Zaretskii wrote:

> > From: Mike Kupfer <kupfer@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