bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ted Zlatanov
Subject: bug#16211: eww should support multiple *eww* buffers
Date: Sun, 22 Dec 2013 17:36:42 -0500
User-agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]