* bug#16211: eww should support multiple *eww* buffers
@ 2013-12-21 11:24 Ivan Shmakov
2013-12-21 20:22 ` Ted Zlatanov
0 siblings, 1 reply; 20+ messages in thread
From: Ivan Shmakov @ 2013-12-21 11:24 UTC (permalink / raw)
To: 16211
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2013-12-21 11:24 bug#16211: eww should support multiple *eww* buffers Ivan Shmakov
@ 2013-12-21 20:22 ` Ted Zlatanov
2013-12-21 21:51 ` Ivan Shmakov
2013-12-23 3:21 ` Stefan Monnier
0 siblings, 2 replies; 20+ messages in thread
From: Ted Zlatanov @ 2013-12-21 20:22 UTC (permalink / raw)
To: Ivan Shmakov; +Cc: Lars Magne Ingebrigtsen, 16211
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2013-12-21 20:22 ` Ted Zlatanov
@ 2013-12-21 21:51 ` Ivan Shmakov
2013-12-22 22:36 ` Ted Zlatanov
2013-12-23 3:21 ` Stefan Monnier
1 sibling, 1 reply; 20+ messages in thread
From: Ivan Shmakov @ 2013-12-21 21:51 UTC (permalink / raw)
To: 16211; +Cc: Lars Magne Ingebrigtsen, Ted Zlatanov
>>>>> "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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2013-12-21 21:51 ` Ivan Shmakov
@ 2013-12-22 22:36 ` Ted Zlatanov
2014-07-06 19:05 ` Ivan Shmakov
0 siblings, 1 reply; 20+ messages in thread
From: Ted Zlatanov @ 2013-12-22 22:36 UTC (permalink / raw)
To: Ivan Shmakov; +Cc: Lars Magne Ingebrigtsen, 16211
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2013-12-21 20:22 ` Ted Zlatanov
2013-12-21 21:51 ` Ivan Shmakov
@ 2013-12-23 3:21 ` Stefan Monnier
2013-12-23 13:11 ` Ted Zlatanov
1 sibling, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2013-12-23 3:21 UTC (permalink / raw)
To: Ivan Shmakov; +Cc: Lars Magne Ingebrigtsen, 16211
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2013-12-23 3:21 ` Stefan Monnier
@ 2013-12-23 13:11 ` Ted Zlatanov
2013-12-23 18:19 ` Ivan Shmakov
2013-12-24 8:05 ` Lars Ingebrigtsen
0 siblings, 2 replies; 20+ messages in thread
From: Ted Zlatanov @ 2013-12-23 13:11 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Lars Magne Ingebrigtsen, 16211, Ivan Shmakov
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2013-12-23 13:11 ` Ted Zlatanov
@ 2013-12-23 18:19 ` Ivan Shmakov
2013-12-23 19:01 ` Glenn Morris
2013-12-24 8:05 ` Lars Ingebrigtsen
1 sibling, 1 reply; 20+ messages in thread
From: Ivan Shmakov @ 2013-12-23 18:19 UTC (permalink / raw)
To: 16211
>>>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2013-12-23 18:19 ` Ivan Shmakov
@ 2013-12-23 19:01 ` Glenn Morris
0 siblings, 0 replies; 20+ messages in thread
From: Glenn Morris @ 2013-12-23 19:01 UTC (permalink / raw)
To: Ivan Shmakov; +Cc: 16211
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.)
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2013-12-23 13:11 ` Ted Zlatanov
2013-12-23 18:19 ` Ivan Shmakov
@ 2013-12-24 8:05 ` Lars Ingebrigtsen
2013-12-24 8:49 ` Ivan Shmakov
1 sibling, 1 reply; 20+ messages in thread
From: Lars Ingebrigtsen @ 2013-12-24 8:05 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 16211, Ivan Shmakov
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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2013-12-24 8:05 ` Lars Ingebrigtsen
@ 2013-12-24 8:49 ` Ivan Shmakov
2014-11-10 21:18 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 20+ messages in thread
From: Ivan Shmakov @ 2013-12-24 8:49 UTC (permalink / raw)
To: 16211; +Cc: Lars Ingebrigtsen
>>>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2013-12-22 22:36 ` Ted Zlatanov
@ 2014-07-06 19:05 ` Ivan Shmakov
2014-11-04 16:42 ` Ted Zlatanov
0 siblings, 1 reply; 20+ messages in thread
From: Ivan Shmakov @ 2014-07-06 19:05 UTC (permalink / raw)
To: 16211
[-- 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.
^ permalink raw reply related [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2014-07-06 19:05 ` Ivan Shmakov
@ 2014-11-04 16:42 ` Ted Zlatanov
0 siblings, 0 replies; 20+ messages in thread
From: Ted Zlatanov @ 2014-11-04 16:42 UTC (permalink / raw)
To: Ivan Shmakov; +Cc: 16211
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2013-12-24 8:49 ` Ivan Shmakov
@ 2014-11-10 21:18 ` Lars Magne Ingebrigtsen
2014-11-19 6:47 ` Ivan Shmakov
0 siblings, 1 reply; 20+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-10 21:18 UTC (permalink / raw)
To: Ivan Shmakov; +Cc: 16211
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2014-11-10 21:18 ` Lars Magne Ingebrigtsen
@ 2014-11-19 6:47 ` Ivan Shmakov
2014-11-19 8:36 ` Ivan Shmakov
2014-11-19 17:38 ` bug#16211: eww should support multiple *eww* buffers Lars Magne Ingebrigtsen
0 siblings, 2 replies; 20+ messages in thread
From: Ivan Shmakov @ 2014-11-19 6:47 UTC (permalink / raw)
To: 16211
[-- 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))
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2014-11-19 6:47 ` Ivan Shmakov
@ 2014-11-19 8:36 ` Ivan Shmakov
2014-11-19 17:41 ` Lars Magne Ingebrigtsen
2014-11-19 17:38 ` bug#16211: eww should support multiple *eww* buffers Lars Magne Ingebrigtsen
1 sibling, 1 reply; 20+ messages in thread
From: Ivan Shmakov @ 2014-11-19 8:36 UTC (permalink / raw)
To: 16211
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2014-11-19 6:47 ` Ivan Shmakov
2014-11-19 8:36 ` Ivan Shmakov
@ 2014-11-19 17:38 ` Lars Magne Ingebrigtsen
1 sibling, 0 replies; 20+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-19 17:38 UTC (permalink / raw)
To: Ivan Shmakov; +Cc: 16211
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#16211: eww should support multiple *eww* buffers
2014-11-19 8:36 ` Ivan Shmakov
@ 2014-11-19 17:41 ` Lars Magne Ingebrigtsen
2014-11-30 9:59 ` bug#19225: eww-render: runs eww-after-render-hook in the (temporary) data buffer Ivan Shmakov
0 siblings, 1 reply; 20+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-11-19 17:41 UTC (permalink / raw)
To: Ivan Shmakov; +Cc: 16211
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19225: eww-render: runs eww-after-render-hook in the (temporary) data buffer
2014-11-19 17:41 ` Lars Magne Ingebrigtsen
@ 2014-11-30 9:59 ` Ivan Shmakov
2014-11-30 10:45 ` Ivan Shmakov
0 siblings, 1 reply; 20+ messages in thread
From: Ivan Shmakov @ 2014-11-30 9:59 UTC (permalink / raw)
To: 19225
[-- 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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19225: eww-render: runs eww-after-render-hook in the (temporary) data buffer
2014-11-30 9:59 ` bug#19225: eww-render: runs eww-after-render-hook in the (temporary) data buffer Ivan Shmakov
@ 2014-11-30 10:45 ` Ivan Shmakov
2014-12-01 17:56 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 20+ messages in thread
From: Ivan Shmakov @ 2014-11-30 10:45 UTC (permalink / raw)
To: 19225, control
[-- 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))
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#19225: eww-render: runs eww-after-render-hook in the (temporary) data buffer
2014-11-30 10:45 ` Ivan Shmakov
@ 2014-12-01 17:56 ` Lars Magne Ingebrigtsen
0 siblings, 0 replies; 20+ messages in thread
From: Lars Magne Ingebrigtsen @ 2014-12-01 17:56 UTC (permalink / raw)
To: 19225
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
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2014-12-01 17:56 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-21 11:24 bug#16211: eww should support multiple *eww* buffers Ivan Shmakov
2013-12-21 20:22 ` Ted Zlatanov
2013-12-21 21:51 ` Ivan Shmakov
2013-12-22 22:36 ` Ted Zlatanov
2014-07-06 19:05 ` Ivan Shmakov
2014-11-04 16:42 ` Ted Zlatanov
2013-12-23 3:21 ` Stefan Monnier
2013-12-23 13:11 ` Ted Zlatanov
2013-12-23 18:19 ` Ivan Shmakov
2013-12-23 19:01 ` Glenn Morris
2013-12-24 8:05 ` Lars Ingebrigtsen
2013-12-24 8:49 ` Ivan Shmakov
2014-11-10 21:18 ` Lars Magne Ingebrigtsen
2014-11-19 6:47 ` Ivan Shmakov
2014-11-19 8:36 ` Ivan Shmakov
2014-11-19 17:41 ` Lars Magne Ingebrigtsen
2014-11-30 9:59 ` bug#19225: eww-render: runs eww-after-render-hook in the (temporary) data buffer Ivan Shmakov
2014-11-30 10:45 ` Ivan Shmakov
2014-12-01 17:56 ` Lars Magne Ingebrigtsen
2014-11-19 17:38 ` bug#16211: eww should support multiple *eww* buffers Lars Magne Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.