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

From: Mike Kupfer <kupfer <at> rawbw.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60423 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, stefankangas <at> gmail.com
Subject: bug#60423: 29.0.60; goto-address and shr/textsec don't play nicely together
Date: Wed, 16 Oct 2024 14:45:39 -0700

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.