GNU bug report logs - #16211
eww should support multiple *eww* buffers

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16211 in the body.
You can then email your comments to 16211 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Ivan Shmakov <ivan <at> siamics.net>
To: submit <at> debbugs.gnu.org
Subject: eww should support multiple *eww* buffers 
Date: Sat, 21 Dec 2013 11:24:54 +0000

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

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

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Ivan Shmakov <ivan <at> siamics.net>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 16211 <at> debbugs.gnu.org
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Sat, 21 Dec 2013 15:22:43 -0500

On Sat, 21 Dec 2013 11:24:54 +0000 Ivan Shmakov <ivan <at> 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

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

From: Ivan Shmakov <ivan <at> siamics.net>
To: 16211 <at> debbugs.gnu.org
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, Ted Zlatanov <tzz <at> lifelogs.com>
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Sat, 21 Dec 2013 21:51:49 +0000

>>>>> "TZ" == Ted Zlatanov <tzz <at> lifelogs.com> writes:
>>>>> On Sat, 21 Dec 2013 11:24:54 +0000 Ivan Shmakov <ivan <at> 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

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

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Ivan Shmakov <ivan <at> siamics.net>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 16211 <at> debbugs.gnu.org
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Sun, 22 Dec 2013 17:36:42 -0500

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

>>>>>> "TZ" == Ted Zlatanov <tzz <at> lifelogs.com> writes:
>>>>>> On Sat, 21 Dec 2013 11:24:54 +0000 Ivan Shmakov <ivan <at> 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

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Ivan Shmakov <ivan <at> siamics.net>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 16211 <at> debbugs.gnu.org
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Sun, 22 Dec 2013 22:21:27 -0500

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

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

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 16211 <at> debbugs.gnu.org,
 Ivan Shmakov <ivan <at> siamics.net>
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Mon, 23 Dec 2013 08:11:35 -0500

On Sun, 22 Dec 2013 22:21:27 -0500 Stefan Monnier <monnier <at> 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

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

From: Ivan Shmakov <ivan <at> siamics.net>
To: 16211 <at> debbugs.gnu.org
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Mon, 23 Dec 2013 18:19:22 +0000

>>>>> Ted Zlatanov <tzz <at> 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

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

From: Glenn Morris <rgm <at> gnu.org>
To: Ivan Shmakov <ivan <at> siamics.net>
Cc: 16211 <at> debbugs.gnu.org
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Mon, 23 Dec 2013 14:01:04 -0500

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.)

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 16211 <at> debbugs.gnu.org, Ivan Shmakov <ivan <at> siamics.net>
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Tue, 24 Dec 2013 09:05:34 +0100

Ted Zlatanov <tzz <at> 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/

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

From: Ivan Shmakov <ivan <at> siamics.net>
To: 16211 <at> debbugs.gnu.org
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Tue, 24 Dec 2013 08:49:47 +0000

>>>>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>>>>> Ted Zlatanov <tzz <at> 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

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

From: Ivan Shmakov <ivan <at> siamics.net>
To: 16211 <at> debbugs.gnu.org
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Sun, 06 Jul 2014 19:05:11 +0000

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

>>>>> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>>>>> On Sat, 21 Dec 2013 21:51:49 +0000 Ivan Shmakov <ivan <at> siamics.net> wrote:
>>>>> "TZ" == Ted Zlatanov <tzz <at> 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/

[Message part 2 (text/x-diff, inline)]

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.
 

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

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Ivan Shmakov <ivan <at> siamics.net>
Cc: 16211 <at> debbugs.gnu.org
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Tue, 04 Nov 2014 11:42:11 -0500

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

>>>>>> Ted Zlatanov <tzz <at> 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

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

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Ivan Shmakov <ivan <at> siamics.net>
Cc: 16211 <at> debbugs.gnu.org
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Mon, 10 Nov 2014 22:18:38 +0100

Ivan Shmakov <ivan <at> 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

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

From: Ivan Shmakov <ivan <at> siamics.net>
To: 16211 <at> debbugs.gnu.org
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Wed, 19 Nov 2014 06:47:12 +0000

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

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

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

--- 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.
 

[Message part 3 (text/diff, inline)]

--- 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))

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

From: Ivan Shmakov <ivan <at> siamics.net>
To: 16211 <at> debbugs.gnu.org
Subject: Re: bug#16211: eww should support multiple *eww* buffers 
Date: Wed, 19 Nov 2014 08:36:37 +0000

	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

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

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Ivan Shmakov <ivan <at> siamics.net>
Cc: 16211 <at> debbugs.gnu.org
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Wed, 19 Nov 2014 18:38:08 +0100

Ivan Shmakov <ivan <at> siamics.net> writes:

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

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

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Ivan Shmakov <ivan <at> siamics.net>
Cc: 16211 <at> debbugs.gnu.org
Subject: Re: bug#16211: eww should support multiple *eww* buffers
Date: Wed, 19 Nov 2014 18:41:37 +0100

Ivan Shmakov <ivan <at> 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

Previous Next

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