[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16211: eww should support multiple *eww* buffers
From: |
Ivan Shmakov |
Subject: |
bug#16211: eww should support multiple *eww* buffers |
Date: |
Tue, 24 Dec 2013 08:49:47 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
>>>>> 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