GNU bug report logs - #19225
eww-render: runs eww-after-render-hook in the (temporary) data buffer

Previous Next

Package: emacs;

Reported by: Ivan Shmakov <ivan <at> siamics.net>

Date: Sun, 30 Nov 2014 10:00:04 UTC

Severity: normal

Tags: fixed, patch

Merged with 19227

Found in version 25.0.50

Fixed in version 25.1

Done: Lars Magne Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ivan Shmakov <ivan <at> siamics.net>
To: 19225 <at> debbugs.gnu.org
Subject: bug#19225: eww-render: runs eww-after-render-hook in the (temporary) data buffer
Date: Sun, 30 Nov 2014 09:59:10 +0000
[Message part 1 (text/plain, inline)]
Package:  emacs

>>>>> Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:
>>>>> Ivan Shmakov <ivan <at> siamics.net> writes:

[…]

 >> The plist-put calls down that progn are evaluated after
 >> eww-display-*, and thus after either eww-setup-buffer or some other
 >> set-buffer.  The eww-use-external-browser-for-content-type case I’m
 >> unsure about, though.

 > I've now removed the statement.

	Following the change for eww-display-* /not/ to change the
	current buffer ($ git log entry MIMEd), those forms are now also
	evaluated in the data buffer.

   283	(defun eww-render (status url &optional point buffer encode)
…
   287	  (let* ((headers (eww-parse-headers))
…
   298		 (data-buffer (current-buffer)))
   299	    (unwind-protect
   300		(progn
…
   316		  (plist-put eww-data :url url)
   317		  (setq eww-history-position 0)
   318		  (run-hooks 'eww-after-render-hook))
   319	      (kill-buffer data-buffer))))

	What’s even worse is that the call to eww-after-render-hook is
	among them, and thus the code there has no (easy) way of finding
	the EWW buffer proper; consider, e. g.:

(add-hook 'eww-after-render-hook
          (lambda () (message "Called in: %S" (current-buffer))))

Called in: #<buffer  *http my.proxy.example:3128*>

	There’re two obvious ways to deal with the issues with eww-data
	and eww-history-position:

	• they could be wrapped into a (with-current-buffer buffer …)
	  form in eww-render;

	• or they could be moved from there to eww-display-raw, -image,
	  and -pdf; (eww-display-html already has them.)

	The eww-after-render-hook case is a bit trickier, as I’d rather
	prefer having some easy way to access /either/ of the buffers
	from the functions referenced.  For instance, I’d like to have a
	way to capture the HTTP header and provide a command to present
	it to the user when asked.  (I doubt this feature really belongs
	to the EWW “core,” so doing it from the hook looks sensible.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A
[Message part 2 (text/plain, inline)]
commit 6fd82d61a2b82e772e8cde0e04516f5c3ca98ed3
Author: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Date:   Sun Nov 23 17:22:41 2014 +0100

    Switch to the *eww* buffer immediately to avoid doing it asynchronously
    
    (eww): Pop to the *eww* buffer immediately after executing the
    `M-x eww' command to avoid having buffers pop up later.
    (eww-display-html): Don't pop the *eww* buffer.
    (eww-display-raw): Ditto.
    (eww-display-image): Ditto.

This bug report was last modified 10 years and 173 days ago.

Previous Next


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