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