GNU bug report logs - #77299
eww-auto-rename-buffer 'title interaction with eww-readable-urls

Previous Next

Full log

Message #11 received at 77299 <at> debbugs.gnu.org (full text, mbox):

From: Keith Amidon <camalot <at> picnicpark.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77299 <at> debbugs.gnu.org
Subject: Re: bug#77299: eww-auto-rename-buffer 'title interaction with
 eww-readable-urls
Date: Tue, 13 May 2025 07:27:09 -0700

[Message part 1 (text/plain, inline)]

On 3/27/25 01:22, Eli Zaretskii wrote:
>> Date: Wed, 26 Mar 2025 11:04:49 -0700
>> From: Keith Amidon<camalot <at> picnicpark.org>
>>
>> I'm trying to use eww with:
>>
>> (setq eww-auto-rename-buffer 'title
>>         eww-readable-urls '((".*" . t)))
>>
>> I'm expecting that this will result in buffer names reflecting
>> the titles of the HTML pages. However, what I actually see is
>> that all buffers get named "Untitled # EWW", made unique by
>> uniquify.
>>
>> This seems like a bug to me.
>>
>> I believe it arises because the title element of eww-data is set
>> to the empty string by eww--before-browse and then set to the
>> actual title when shr-insert-document csiteslalls the eww-tag-title
>> function via the shr-external-rendering-functions set in
>> eww-display-document.
>>
>> I think that in the readable case, the content passed to
>> shr-insert-document does not include the title element so
>> it isn't available from rendering that content.
>>
>> It appears to me that eww-readable preserves the title
>> in the eww-data plist by resetting it after calling
>> eww-before-browse. And in fact, if I set eww-readable-urls to
>> nil and go to a site, the buffer is properly named based on
>> the title. If I then call eww-readable, it remains named
>> based on the title.
>>
>> The default readability based-on eww-readable-urls appears
>> to happen in eww-display-html, which itself calls
>> eww-display-document. The full document hasn't been rendered
>> at this point so there is no existing title to preserve.
>>
>> I don't think there is a simple fix for this. The fundamental
>> problem is that eww only gets the title by rendering the
>> original document and in the case of default readable URLs
>> it never renders the original document. I thought it might be
>> possible to hack eww-score-readability to include the title
>> in the readable version but it appears that it is omitting the
>> entire head section currently, so it would need fairly
>> extensive changes to selectively pass through the title
>> without any other head elements.
> I agree with your analysis: it's a design problem, which prevents
> shr-insert-document from calling eww-tag-title, and thus the title
> remains the empty string.  IOW, eww-readable-urls is currently
> incompatible with eww-auto-rename-buffer, and moreover, it causes the
> URL to be shown as "untitled", even if eww-auto-rename-buffer is not
> used.
>
> Hopefully, someone who knows this code and how shr.el works will be
> able to come up with a solution.  One possible way is to find the
> title before calling shr-insert-document, and then manually setting
> the :title property of eww-data when shr-insert-document returns.
>
Sorry it took so long for me to get back to looking into this more
and thus for the long quote above to re-establish context. I have
found that I seem to be able to get eww-auto-rename-buffer 'title,
history titles, and org link capture to work with default readable
URLs in eww-readable-urls by redefining eww-display-html to:

(defun eww-display-html (charset url &optional document point buffer)
  (let ((source (buffer-substring (point) (point-max))))
    (with-current-buffer buffer
      (plist-put eww-data :source source)))
  (eww-display-document
   (or document
       (eww-document-base url (eww--parse-html-region (point) (point-max) charset)))
   point buffer)
  (and (null document)
       (eww-default-readable-p url)
       (with-current-buffer buffer
         (eww-readable 1))))

This is somewhat less efficient than the prior implementation in that
the document gets displayed twice for default readable URLs, but it is
no worse than not having default readability and manually toggling
readability after the page is rendered.

I haven't noticed any downsides to this redefinition yet, but I've
only been playing around with it for a morning so far. Given it
reduces the conflict between eww-readable-urls and multiple other
features, it seems worth considering.

--- Keith

[Message part 2 (text/html, inline)]

Previous Next

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