GNU bug report logs -
#58118
29.0.50; Follow #target links in eww without re-rendering page
Previous Next
Reported by: Visuwesh <visuweshm <at> gmail.com>
Date: Tue, 27 Sep 2022 15:39:01 UTC
Severity: wishlist
Tags: patch
Found in version 29.0.50
Done: Stefan Kangas <stefankangas <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Visuwesh <visuweshm <at> gmail.com> writes:
> eww-follow-link currently follows #target links in the same URL by
> re-rendering the page. Whilst this is fine for small HTML files, the
> 1.9M HTML file that I'm currently visiting takes a couple seconds to
> render.
That's a regression, I think -- following #target links used to work
without re-rendering. (At least it did at one point.)
> I see that eww-display-html follows #target links by a text property
> search, why don't we do the same in eww-follow-link as well? I have one
> question though: what do we about non-existent #targets? Chrome and
> Firefox seem to not scroll when I add a non-existent #target to the
> current URL and say RET, and it seems to specially handle #top to mean
> to go to the top even if the HTML has no hits for "#top". Should we
> handle the special #top target?
Sure, makes sense.
> + (setq match (text-property-search-forward 'shr-target-id target #'member))
> + (if match
> + (goto-char (prop-match-beginning match))
This is more conveniently expressed as
(when-let ((text-property-search-forward 'shr-target-id target #'member))
(goto-char (prop-match-beginning match)))
This bug report was last modified 2 years and 245 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.