Package:  emacs

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>>>> Ivan Shmakov <ivan@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