bug#16211: eww should support multiple *eww* buffers

bug#16211: eww should support multiple *eww* buffers

[Ivan Shmakov]

Package:  emacs
Severity: wishlist

	EWW should support rendering Web pages in more than one buffer
	(akin to “tabs” and “windows” of many other browsers out there.)

	This could’ve been a matter of a single variable, made local
	(and non-nil) in ‘*eww*’ buffers, but as eww-render is called
	from the /data/ buffer (and not the buffer the Web page was
	requested from), it’s likely to be necessary to pass the buffer
	to eww-render explicitly, whenever it’s called via url-retrieve.

	For simplicity, eww-render may then dynamically bind some
	variable to the buffer passed, which is then to be used by
	eww-setup-buffer (instead of requesting the ‘*eww*’ buffer.)

	Then, to get a new buffer to render Web pages in, we simply
	create one, and call eww-mode from there.  (The latter flagging
	the buffer as suitable for rendering, perhaps re-using the very
	same variable as bound dynamically by eww-render above, only
	making it local to the buffer.)

PS.  And while there, why not to make the buffer names used by EWW
	customizable, BTW?

-- 
FSF associate member #7257

bug#16211: eww should support multiple *eww* buffers

[Ted Zlatanov]

On Sat, 21 Dec 2013 11:24:54 +0000 Ivan Shmakov <ivan@siamics.net> wrote: 

IS> Package:  emacs
IS> Severity: wishlist

IS> 	EWW should support rendering Web pages in more than one buffer
IS> 	(akin to “tabs” and “windows” of many other browsers out there.)

I agree, but Lars and Stefan may not.  They prefer (based on a
discussion in emacs-devel just recently) a more Emacsian behavior where
possible, instead of mimicking regular web browsers.

IS> PS.  And while there, why not to make the buffer names used by EWW
IS> 	customizable, BTW?

I agree this functionality would be nice, see `eww-setup-buffer'.
Should be pretty trivial.

I don't see a need for complicated variable passing as you described and
I omitted, but have no strong opinion about it either.

Ted

bug#16211: eww should support multiple *eww* buffers

[Ivan Shmakov]

>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
>>>>> On Sat, 21 Dec 2013 11:24:54 +0000 Ivan Shmakov <ivan@siamics.net> wrote:

 IS> Package: emacs Severity: wishlist

 IS> EWW should support rendering Web pages in more than one buffer
 IS> (akin to “tabs” and “windows” of many other browsers out there.)

 TZ> I agree, but Lars and Stefan may not.  They prefer (based on a
 TZ> discussion in emacs-devel just recently) a more Emacsian behavior
 TZ> where possible, instead of mimicking regular web browsers.

	Well, I have no problem with that: Gnus uses different Summary
	buffers for different groups, M-x mml-preview keeps creating new
	buffers even if called for the very same message buffer, and
	well, find-file isn’t constrained to a single buffer, either.

 IS> PS.  And while there, why not to make the buffer names used by EWW
 IS> customizable, BTW?

 TZ> I agree this functionality would be nice, see `eww-setup-buffer'.
 TZ> Should be pretty trivial.

	Yes, I know: I’ve already patched the code.  (I’ve tried to
	contact assign at gnu dot org for copyright disclaimer papers,
	but haven’t received any reply so far.  And now I guess I’d have
	to wait to the next year due to the holidays, anyway.)

 TZ> I don't see a need for complicated variable passing as you
 TZ> described and I omitted, but have no strong opinion about it
 TZ> either.

	Please note that eww-setup-buffer is called from the buffer
	filled by url-retrieve, and /not/ from one of the EWW buffers.
	I see no obvious way for it to deduce from which buffer the
	original command (say, M-x eww) was called so to get back there.

-- 
FSF associate member #7257

bug#16211: eww should support multiple *eww* buffers

[Ted Zlatanov]

On Sat, 21 Dec 2013 21:51:49 +0000 Ivan Shmakov <ivan@siamics.net> wrote: 

>>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
>>>>>> On Sat, 21 Dec 2013 11:24:54 +0000 Ivan Shmakov <ivan@siamics.net> wrote:

IS> Package: emacs Severity: wishlist

IS> EWW should support rendering Web pages in more than one buffer
IS> (akin to “tabs” and “windows” of many other browsers out there.)

TZ> I agree, but Lars and Stefan may not.  They prefer (based on a
TZ> discussion in emacs-devel just recently) a more Emacsian behavior
TZ> where possible, instead of mimicking regular web browsers.

IS> 	Well, I have no problem with that: Gnus uses different Summary
IS> 	buffers for different groups, M-x mml-preview keeps creating new
IS> 	buffers even if called for the very same message buffer, and
IS> 	well, find-file isn’t constrained to a single buffer, either.

Actually Lars specifically said eww is not like Gnus.  Please read the
discussion; do you need a URL?

IS> PS.  And while there, why not to make the buffer names used by EWW
IS> customizable, BTW?

TZ> I agree this functionality would be nice, see `eww-setup-buffer'.
TZ> Should be pretty trivial.

IS> 	Yes, I know: I’ve already patched the code.  (I’ve tried to
IS> 	contact assign at gnu dot org for copyright disclaimer papers,
IS> 	but haven’t received any reply so far.  And now I guess I’d have
IS> 	to wait to the next year due to the holidays, anyway.)

Well, no rush on this, it's not a bug or a critical feature...

TZ> I don't see a need for complicated variable passing as you
TZ> described and I omitted, but have no strong opinion about it
TZ> either.

IS> 	Please note that eww-setup-buffer is called from the buffer
IS> 	filled by url-retrieve, and /not/ from one of the EWW buffers.
IS> 	I see no obvious way for it to deduce from which buffer the
IS> 	original command (say, M-x eww) was called so to get back there.

Right, OK.  I will let you and Lars figure it out, but if you can
propose a patch to accomplish what you describe, it will probably speed
things up.

Ted

bug#16211: eww should support multiple *eww* buffers

[Stefan Monnier]

IS> EWW should support rendering Web pages in more than one buffer
IS> (akin to “tabs” and “windows” of many other browsers out there.)
> I agree, but Lars and Stefan may not.  They prefer (based on a
> discussion in emacs-devel just recently) a more Emacsian behavior where
> possible, instead of mimicking regular web browsers.

Not sure what you're thinking of.  I've spent a fair deal of time
hacking on info.el so that we could have several Info buffers at the
same time.  Same for PCL-CVS, *Help* and a few others.

Emacs is an Operating System.  So of course, we want to be able to have
several eww buffers at the same time.


        Stefan

bug#16211: eww should support multiple *eww* buffers

[Ted Zlatanov]

On Sun, 22 Dec 2013 22:21:27 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

IS> EWW should support rendering Web pages in more than one buffer
IS> (akin to “tabs” and “windows” of many other browsers out there.)
>> I agree, but Lars and Stefan may not.  They prefer (based on a
>> discussion in emacs-devel just recently) a more Emacsian behavior where
>> possible, instead of mimicking regular web browsers.

SM> Not sure what you're thinking of.  I've spent a fair deal of time
SM> hacking on info.el so that we could have several Info buffers at the
SM> same time.  Same for PCL-CVS, *Help* and a few others.

SM> Emacs is an Operating System.  So of course, we want to be able to have
SM> several eww buffers at the same time.

I was talking about "tabs" and "windows" specifically, which imply a
collection of eww buffers should be somehow associated.  Anyhow, as I
said, I'm in favor of this as well, I just didn't want to assume this
direction was desirable.

Ted

bug#16211: eww should support multiple *eww* buffers

[Ivan Shmakov]

>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>>>>> On Sun, 22 Dec 2013 22:21:27 -0500 Stefan Monnier wrote:

 >>>> EWW should support rendering Web pages in more than one buffer
 >>>> (akin to “tabs” and “windows” of many other browsers out there.)

 >>> I agree, but Lars and Stefan may not.  They prefer (based on a
 >>> discussion in emacs-devel just recently) a more Emacsian behavior
 >>> where possible, instead of mimicking regular web browsers.

[…]

 >> Emacs is an Operating System.  So of course, we want to be able to
 >> have several eww buffers at the same time.

 > I was talking about "tabs" and "windows" specifically, which imply a
 > collection of eww buffers should be somehow associated.  Anyhow, as I
 > said, I'm in favor of this as well, I just didn't want to assume this
 > direction was desirable.

	FTR, it wasn’t my intent to imply any sort of such association.
	(Apart from the one arising from the fact that the EWW buffers
	being discussed are to belong to the same Emacs process.)

-- 
FSF associate member #7257

bug#16211: eww should support multiple *eww* buffers

[Glenn Morris]

Massively off-topic:

OK, so I'm finally going to bite and say that I have never seen anyone
indent their own text in emails (and unindent quoted material). Where
did you get this habit from? I find it a bit strange to read.

(This is the _exact_ opposite of the convention used by rms, for
example.)

bug#16211: eww should support multiple *eww* buffers

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I was talking about "tabs" and "windows" specifically, which imply a
> collection of eww buffers should be somehow associated.  Anyhow, as I
> said, I'm in favor of this as well, I just didn't want to assume this
> direction was desirable.

I'm not sure I quite see the value in grouping eww buffers in tabs, but
it should be possible to just rename an eww buffer and create new ones
with `M-x eww'.  That's almost possible now, perhaps?  The eww buffer
uses only buffer-local variables (or is supposed to), so things should,
like work.

But I haven't tried doing that at all, so the likelihood of that working
is probably zero.  >"?  But it should be fixable.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#16211: eww should support multiple *eww* buffers

[Ivan Shmakov]

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:

 >> I was talking about "tabs" and "windows" specifically, which imply a
 >> collection of eww buffers should be somehow associated.  Anyhow, as
 >> I said, I'm in favor of this as well, I just didn't want to assume
 >> this direction was desirable.

 > I'm not sure I quite see the value in grouping eww buffers in tabs,
 > but it should be possible to just rename an eww buffer and create new
 > ones with `M-x eww'.  That's almost possible now, perhaps?  The eww
 > buffer uses only buffer-local variables (or is supposed to), so
 > things should, like work.

 > But I haven't tried doing that at all, so the likelihood of that
 > working is probably zero.  >"?  But it should be fixable.

	The problem is that trying to M-x eww, or to follow a link, in
	such a renamed buffer, results in the target document still
	being rendered in the *eww* buffer.

	As I’ve already mentioned [1, 2], it happens because
	url-retrieve (as called by M-x eww and M-x eww-reload) calls its
	callback (which is eww-render in these cases) /not/ in the
	original buffer, but instead in a buffer holding the data
	fetched from the URI specified.  Which makes it necessary to
	pass the original buffer (the one from which M-x eww is called)
	to eww-render (through the ‘cbargs’ argument to url-retrieve.)

	Then, eww-render may pass the buffer to eww-setup-buffer, either
	via a dynamically-bound variable, or as an argument.
	(Alternatively, eww-render may switch to the buffer by itself.)

[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16211#5
[2] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16211#11

-- 
FSF associate member #7257

bug#16211: eww should support multiple *eww* buffers

[Ivan Shmakov]

[-- Attachment #1: Type: text/plain, Size: 2178 bytes --]

>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>>>>> On Sat, 21 Dec 2013 21:51:49 +0000 Ivan Shmakov <ivan@siamics.net> wrote:
>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:

[…]

 TZ> I don't see a need for complicated variable passing as you
 TZ> described and I omitted, but have no strong opinion about it
 TZ> either.

 IS> Please note that eww-setup-buffer is called from the buffer filled
 IS> by url-retrieve, and /not/ from one of the EWW buffers.  I see no
 IS> obvious way for it to deduce from which buffer the original command
 IS> (say, M-x eww) was called so to get back there.

 TZ> Right, OK.  I will let you and Lars figure it out, but if you can
 TZ> propose a patch to accomplish what you describe, it will probably
 TZ> speed things up.

	Well, I’ve tried to contact assign at gnu dot org and
	copyright-clerk at fsf dot org once again some weeks ago, and
	got no reply again.  I wonder if it has anything to do with the
	way my MXes work (though I clearly see the message being
	accepted by one of the FSF/GNU ones in the logs), or that I’ve
	requested a copyright /disclaimer/ (for I believe that these of
	my changes are non-copyrightable per se anyway.)

	Nevertheless, the patch that I use for quite some time is MIMEd.
	And just in case the changes I suggest /are/ copyrightable,
	here’s the license for them:

To the extent possible under law, the author(s) have dedicated all
copyright and related and neighboring rights to this software to the
public domain worldwide.  This software is distributed without any
warranty.

You should have received a copy of the CC0 Public Domain Dedication
along with this software.  If not, see
<http://creativecommons.org/publicdomain/zero/1.0/>.

	Note though that there’re a few changes not strictly necessary.
	For instance, eww-setup-buffer now uses set-buffer instead of
	switch-to-buffer, so that it’s possible to start eww-reload in
	several EWW buffers in a row, without being switched from one to
	another at some random point.  Also, there’s a new
	eww-buffer-name variable.

-- 
FSF associate member #7257	http://boycottsystemd.org/

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff, Size: 4100 bytes --]

diff --git a/lisp/net/eww.el b/lisp/net/eww.el
index 02fc575..738e462 100644
--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -57,6 +57,12 @@
   :group 'eww
   :type 'string)
 
+(defcustom eww-buffer-name "*eww*"
+  "Buffer name to use for rendering HTML."
+  :version "24.4"
+  :group 'eww
+  :type 'string)
+
 (defcustom eww-use-external-browser-for-content-type
   "\\`\\(video/\\|audio/\\|application/ogg\\)"
   "Always use external browser for specified content-type."
@@ -125,6 +131,7 @@ See also `eww-form-checkbox-selected-symbol'."
   :group 'eww)
 
 (defvar eww-current-url nil)
+(defvar eww-current-buffer nil)
 (defvar eww-current-dom nil)
 (defvar eww-current-source nil)
 (defvar eww-current-title ""
@@ -169,7 +176,8 @@ word(s) will be searched for via `eww-search-prefix'."
                  (setq url (concat url "/"))))
            (setq url (concat eww-search-prefix
                              (replace-regexp-in-string " " "+" url))))))
-  (url-retrieve url 'eww-render (list url)))
+  (url-retrieve url 'eww-render
+		(list url nil eww-current-buffer)))
 
 ;;;###autoload (defalias 'browse-web 'eww)
 
@@ -182,7 +190,7 @@ word(s) will be searched for via `eww-search-prefix'."
 		    "/")
 	       (expand-file-name file))))
 
-(defun eww-render (status url &optional point)
+(defun eww-render (status url &optional point buffer)
   (let ((redirect (plist-get status :redirect)))
     (when redirect
       (setq url redirect)))
@@ -199,8 +207,10 @@ word(s) will be searched for via `eww-search-prefix'."
 			"utf8"))))
 	 (data-buffer (current-buffer)))
     (unwind-protect
-	(progn
-          (setq eww-current-title "")
+	(let ((eww-current-buffer (or buffer
+				      eww-current-buffer)))
+	  (with-current-buffer eww-current-buffer
+	    (setq eww-current-title ""))
 	  (cond
            ((and eww-use-external-browser-for-content-type
                  (string-match-p eww-use-external-browser-for-content-type
@@ -258,10 +268,11 @@ word(s) will be searched for via `eww-search-prefix'."
 	 (or document
 	     (list
 	      'base (list (cons 'href url))
-	      (libxml-parse-html-region (point) (point-max))))))
-    (setq eww-current-source (buffer-substring (point) (point-max)))
+	      (libxml-parse-html-region (point) (point-max)))))
+	(source (buffer-substring (point) (point-max))))
     (eww-setup-buffer)
-    (setq eww-current-dom document)
+    (setq eww-current-dom document
+	  eww-current-source source)
     (let ((inhibit-read-only t)
 	  (after-change-functions nil)
 	  (shr-width nil)
@@ -381,8 +392,12 @@ word(s) will be searched for via `eww-search-prefix'."
       (shr-put-image data nil))
     (goto-char (point-min))))
 
-(defun eww-setup-buffer ()
-  (switch-to-buffer (get-buffer-create "*eww*"))
+(defun eww-setup-buffer (&optional buffer)
+  (set-buffer
+   (cond ((not buffer)      (or eww-current-buffer
+				(get-buffer-create eww-buffer-name)))
+	 ((bufferp buffer)  buffer)
+	 (t (generate-new-buffer (or buffer eww-buffer-name)))))
   (let ((inhibit-read-only t))
     (remove-overlays)
     (erase-buffer))
@@ -401,7 +416,7 @@ word(s) will be searched for via `eww-search-prefix'."
         (source eww-current-source))
     (with-current-buffer buf
       (delete-region (point-min) (point-max))
-      (insert (or eww-current-source "no source"))
+      (insert (or source "no source"))
       (goto-char (point-min))
       (when (fboundp 'html-mode)
         (html-mode)))
@@ -479,6 +494,7 @@ word(s) will be searched for via `eww-search-prefix'."
   (setq-local eww-current-dom nil)
   (setq-local eww-current-source nil)
   (setq-local eww-current-title "")
+  (setq-local eww-current-buffer (current-buffer))
   (setq-local browse-url-browser-function 'eww-browse-url)
   (setq-local after-change-functions 'eww-process-text-input)
   (setq-local eww-history nil)
@@ -567,7 +583,7 @@ appears in a <link> or <a> tag."
   "Reload the current page."
   (interactive)
   (url-retrieve eww-current-url 'eww-render
-		(list eww-current-url (point))))
+		(list eww-current-url (point) eww-current-buffer)))
 
 ;; Form support.
 

bug#16211: eww should support multiple *eww* buffers

[Ted Zlatanov]

On Sun, 06 Jul 2014 19:05:11 +0000 Ivan Shmakov <ivan@siamics.net> wrote: 

>>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:

TZ> Right, OK.  I will let you and Lars figure it out, but if you can
TZ> propose a patch to accomplish what you describe, it will probably
TZ> speed things up.

IS> 	Well, I’ve tried to contact assign at gnu dot org and
IS> 	copyright-clerk at fsf dot org once again some weeks ago, and
IS> 	got no reply again.

Lars, Stefan, can you help Ivan with a review of his patch and checking
for his assignment papers?

Ted

bug#16211: eww should support multiple *eww* buffers

[Lars Magne Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

> 	The problem is that trying to M-x eww, or to follow a link, in
> 	such a renamed buffer, results in the target document still
> 	being rendered in the *eww* buffer.

This has now been fixed on the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16211: eww should support multiple *eww* buffers

[Ivan Shmakov]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

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

 >> The problem is that trying to M-x eww, or to follow a link, in such
 >> a renamed buffer, results in the target document still being
 >> rendered in the *eww* buffer.

 > This has now been fixed on the trunk.

	Not quite.  Please consider the patch MIMEd.

	I’d also prefer for the name of the default EWW buffer to be
	customizable (another patch MIMEd), but that’s another story.

-- 
FSF associate member #7257  np. Čohkka — Apocalyptica   … 3013 B6A0 230E 334A

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/diff, Size: 331 bytes --]

--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -664,7 +664,8 @@ defun eww-reload ()
   "Reload the current page."
   (interactive)
   (let ((url (plist-get eww-data :url)))
-    (url-retrieve url 'eww-render (list url (point)))))
+    (url-retrieve url 'eww-render
+		  (list url (point) (current-buffer)))))
 
 ;; Form support.
 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Type: text/diff, Size: 704 bytes --]

--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -65,6 +65,12 @@
   :group 'eww
   :type 'string)
 
+(defcustom eww-buffer-name "*eww*"
+  "Buffer name to use for rendering HTML."
+  :version "25.1"
+  :group 'eww
+  :type 'string)
+
 (defcustom eww-use-external-browser-for-content-type
   "\\`\\(video/\\|audio/\\|application/ogg\\)"
   "Always use external browser for specified content-type."
@@ -422,7 +459,7 @@ See the `eww-search-prefix' variable for the search engine used."
   (switch-to-buffer
    (if (buffer-live-p buffer)
        buffer
-     (get-buffer-create "*eww*")))
+     (get-buffer-create eww-buffer-name)))
   (let ((inhibit-read-only t))
     (remove-overlays)
     (erase-buffer))

bug#16211: eww should support multiple *eww* buffers

[Ivan Shmakov]

	One another issue, – the following plist-put does nothing, as
	it’s evaluated while still in the url.el “data buffer” (for
	which eww-data is most likely nil):

   208	(defun eww-render (status url &optional point buffer)
…
   212	  (let* ((headers (eww-parse-headers))
…
   223		 (data-buffer (current-buffer)))
   224	    (unwind-protect
   225		(progn
   226	          (plist-put eww-data :title "")

	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.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

bug#16211: eww should support multiple *eww* buffers

[Lars Magne Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

>>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>>>>> Ivan Shmakov <ivan@siamics.net> writes:
>
>  >> The problem is that trying to M-x eww, or to follow a link, in such
>  >> a renamed buffer, results in the target document still being
>  >> rendered in the *eww* buffer.
>
>  > This has now been fixed on the trunk.
>
> 	Not quite.  Please consider the patch MIMEd.

Thanks; applied.

> 	I’d also prefer for the name of the default EWW buffer to be
> 	customizable (another patch MIMEd), but that’s another story.

I don't think that needs to be a variable.  If you want a different
name, you can write a hook function.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16211: eww should support multiple *eww* buffers

[Lars Magne Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

> 	One another issue, – the following plist-put does nothing, as
> 	it’s evaluated while still in the url.el “data buffer” (for
> 	which eww-data is most likely nil):
>
>    208	(defun eww-render (status url &optional point buffer)
> …
>    212	  (let* ((headers (eww-parse-headers))
> …
>    223		 (data-buffer (current-buffer)))
>    224	    (unwind-protect
>    225		(progn
>    226	          (plist-put eww-data :title "")
>
> 	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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Ivan Shmakov]

[-- Attachment #1: Type: text/plain, Size: 2100 bytes --]

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

[-- Attachment #2: Type: text/plain, Size: 459 bytes --]

commit 6fd82d61a2b82e772e8cde0e04516f5c3ca98ed3
Author: Lars Magne Ingebrigtsen <larsi@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.

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

[Ivan Shmakov]

[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]

tags 19225 + patch
thanks

>>>>> Ivan Shmakov <ivan@siamics.net> writes:
>>>>> 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.

	… As well as a couple of eww-update-header-line-format calls.

	Please consider the patch MIMEd.  This one doesn’t pass the data
	buffer to eww-after-render-hook, and I hope this still could be
	resolved a bit later.

	* eww.el (eww-render): Call eww-update-header-line-format
	unconditionally and in the browsing buffer (was: data buffer);
	change eww-data and eww-history-position for the browsing
	buffer, and run eww-after-render-hook there, too.
	(eww-display-html): Do not call eww-update-header-line-format or
	change eww-data, eww-history-position (now done in eww-render.)

   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
   301		  (cond
…
   310		   ((string-match-p "\\`image/" (car content-type))
   311		    (eww-display-image buffer)
   312		    (eww-update-header-line-format))
   313		   (t
   314		    (eww-display-raw buffer encode)
   315		    (eww-update-header-line-format)))
   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))))

[…]

-- 
FSF associate member #7257  np. Surrender — Jami Sieber … 3013 B6A0 230E 334A

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/diff, Size: 1296 bytes --]

--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -308,14 +315,14 @@ defun eww-render (status url &optional point buffer encode)
 	   ((equal (car content-type) "application/pdf")
 	    (eww-display-pdf))
 	   ((string-match-p "\\`image/" (car content-type))
-	    (eww-display-image buffer)
-	    (eww-update-header-line-format))
+	    (eww-display-image buffer))
 	   (t
-	    (eww-display-raw buffer encode)
-	    (eww-update-header-line-format)))
-	  (plist-put eww-data :url url)
-	  (setq eww-history-position 0)
-	  (run-hooks 'eww-after-render-hook))
+	    (eww-display-raw buffer encode)))
+	  (with-current-buffer buffer
+	    (plist-put eww-data :url url)
+	    (eww-update-header-line-format)
+	    (setq eww-history-position 0)
+	    (run-hooks 'eww-after-render-hook)))
       (kill-buffer data-buffer))))
 
 (defun eww-parse-headers ()
@@ -403,10 +411,7 @@ defun eww-display-html (charset url &optional document point buffer encode)
 	  (while (and (not (eobp))
 		      (get-text-property (point) 'eww-form))
 	    (forward-line 1)))))
-      (plist-put eww-data :url url)
-      (setq eww-history-position 0)
-      (eww-size-text-inputs)
-      (eww-update-header-line-format))))
+      (eww-size-text-inputs))))
 
 (defun eww-handle-link (dom)
   (let* ((rel (dom-attr dom 'rel))

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

[Lars Magne Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

> 	Please consider the patch MIMEd.  This one doesn’t pass the data
> 	buffer to eww-after-render-hook, and I hope this still could be
> 	resolved a bit later.

Thanks; applied.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no