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

[Mike Kupfer <kupfer@rawbw.com>]

Eli Zaretskii wrote:

> AFAIU from your analysis of the problem, it happens because the same
> text is covered by both a text property and an overlay with the same
> property.  If that is indeed the reason, then the only conflict that I
> could see in this situation is for the 'face' property: both shr-tag-a
> and goto-address use it, one as a text property and the other as an
> overlay property.  The other properties you mention aren't used by
> goto-address, so they cannot conflict with what shr-tag-a.  Am I
> missing something?

Yes, goto-address also sets the 'help-echo' and 'mouse-face' properties,
though the latter is only set for email addresses.  (Sorry, I didn't
call this out in my earlier email.)

> Testing unrelated properties might give us false positives, so I think
> we should avoid that.

Agreed about trying to avoid false positives.

The complete list of overlay properties that goto-address-fontify sets
is

- evaporate
- face
- follow-link
- goto-address
- help-echo
- keymap
- mouse-face

We agree about checking for 'face'.  I'm still holding out for checking
for 'help-echo' and 'mouse-face'.  After reviewing the documentation for
the other properties, I'd also like to check for 'keymap' and
'follow-link'.  I don't see a reason to check for 'evaporate'.
'goto-address' is not documented and appears to be used to mark the
overlay as belonging to goto-address, so no need to check for it.

mike