"Basil L. Contovounesios" writes: > Lars Ingebrigtsen writes: > >> "Basil L. Contovounesios" writes: >> >>> Perhaps shr should unconditionally (without requiring shr-target-id to >>> be bound) mark all possible targets with text properties during >>> rendering. I'll see if I can get this or any other way working today or >>> tomorrow, but either way this won't be fixed in Emacs 27. >> >> Hm... marking all the targets sounds like overkill (if I understand you >> correctly, but it's likely that I don't). :-) > > Marking all the targets is what I meant, but I was only thinking aloud, > not seriously suggesting it. I'm still stepping through eww and shr > trying to figure out why shr-target-id doesn't work sometimes (my > current guess is shr modifies the DOM to avoid re-rendering tables, so > shr-target-id doesn't get set in such cases); progress is slow. :( Now that I understand what's happening better, I think it's necessary to mark all targets, and I don't think it's overkill. The problem is indeed that shr caches rendered tables. What this means is that, if eww first visits a URL with no #target, then its tables will be rendered and cached with no shr-target-id text property attached to any fragment identifiers contained within them. If eww-follow-link is subsequently invoked on a #target within the same page, then the cached table contents will be inserted and so there will be no shr-target-id property in the buffer. The recipe provided in [1] illustrates this. [1]: https://debbugs.gnu.org/40532#51 OTOH if the shr-target-id property is always attached to the relevant 'id' and (deprecated) 'name' attributes, then cached table contents will still be searchable. This shouldn't be overkill in terms of performance because yet another text property on a subet of the DOM should be comparatively cheap, right? So WDYT of the following fix? Can you think of any better solutions?