Re: w3m-clear-display-while-reading vs C-c C-k stop

[Boruch Baum <boruch_baum@xxxxxxx>]

Hi Kevin,

I don't know if this operational work-around will satisfy you, but
I'll offer what I recall has worked for me in the past. After I stop
the sub-process, I just type 'U' (or was it 'g'?), and the default URL
in the minibuffer is that of the stopped sub-process.

This would happen to me when I open 'too many' pages too quickly, and
have 'too many' parrallel downloads. As background, my use case is
that I have an instance of 'newsbeuter' sending URL's to the emacs w3m
server via calls to emacs-client, so while I'm scanning rss summaries
in the foreground with newsbeuter, the emacs w3m server is downloading
in the background full rss articles that I'm deciding to read later in
their entirety.

Regards,



On 2017-03-14 10:46, Kevin Ryde wrote:
> When w3m-clear-display-while-reading is t (the default), if a web server
> is unresponsive then going C-c C-k to stop the sub-process (as invited
> by the usual echo area message) leaves the display cleared and showing
> "Reading http://...";
>
> I wonder if C-c C-k could redraw the page it came from.  The status bar
> seems to show the title, but no content in the buffer.  If a cancel of
> the first fetch of a session then maybe blank or something.
>
> A bit of netcat locally can cook up an unresponsive server to see the
> effect.  I've usually struck it on domains gone or down.
>
>     netcat -l -p 12345
>
> then in emacs
>
>     M-x w3m
>     g http://localhost:12345/
>     C-c C-k
>     =>
>     still shows "Reading ..."
>
>

--

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0