Async pre-treatment of articles

Async pre-treatment of articles

[Lars Magne Ingebrigtsen]

Reading articles with pictures external pictures in them (for instance,
the Gwene groups) is somewhat awkward.  You first get the text, and then
a few second later, the pictures are filled in, and the text moves
around.  It's annoying.

I thought at first that the problem was that Emacs displayed the
pictures slowly, but the problem is probably just that it takes a while
for w3m to fetch the images.  Re-reading articles where w3m has cached
the images is very fast.

So my immediate idea would be to add some sort of async pre-rendering of
messages.  That is, from the nntp pre-fetch code (or somewhere), point
w3m at the message.  However, for that to happen, Gnus really has to do
all the decoding and charset stuff and Content-Transfer-Encoding stuff,
so that's a pretty big chunk of code to run from an async hook...

However, it occurs to me just now that if we special-case for CTE: 8bit,
then I could just point w3m at a throwaway buffer containing the next
article(s), and let it do its stuff there...

Would that be to special-casey for general usefulness? 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Async pre-treatment of articles

[Adam Sjøgren]

On Sat, 28 Aug 2010 22:27:00 +0200, Lars wrote:

> I thought at first that the problem was that Emacs displayed the
> pictures slowly, but the problem is probably just that it takes a while
> for w3m to fetch the images.  Re-reading articles where w3m has cached
> the images is very fast.

It feels to me like it is orders of magnitude slower at this than
web-browsers like Firefox. Isn't that odd? It almost feels like it
doesn't start right away.


  Best regards,

    Adam

-- 
 "Angels can fly because they take themselves lightly."       Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Async pre-treatment of articles

[Adam Sjøgren]

On Sat, 28 Aug 2010 22:34:38 +0200, Adam wrote:

> It feels to me like it is orders of magnitude slower at this than
> web-browsers like Firefox. Isn't that odd? It almost feels like it
> doesn't start right away.

Looking at the http port with ngrep seems to confirm this. The article
is displayed, and a number of seconds (3-10) later, requests start going
out for the images.

What is it spending its time doing?


  Best regards,

    Adam

-- 
 "Angels can fly because they take themselves lightly."       Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Async pre-treatment of articles

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> Looking at the http port with ngrep seems to confirm this. The article
> is displayed, and a number of seconds (3-10) later, requests start going
> out for the images.

Oh, right.  Yeah, w3m does seem ridiculously slow in fetching pictures.
Perhaps I should peek at the w3m code instead.

Meanwhile, has anybody written a handy "how to use git from within Emacs
if you're used to cvs-update and vc-mode...  FOR DUMMIES"?

I managed to check out the Gnus repository with password and stuff, but
I'm not able to find out what magical keys to push to check stuff in
again.  (Yeah, I know, it's probably "push" in git parlance.  But I'm
covering my ears.  LA LA LA LA LA.  I can't hear you.  LA LA LA.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Async pre-treatment of articles

[Adam Sjøgren]

On Sat, 28 Aug 2010 22:44:59 +0200, Lars wrote:

> asjo@koldfront.dk (Adam Sjøgren) writes:
>> Looking at the http port with ngrep seems to confirm this. The article
>> is displayed, and a number of seconds (3-10) later, requests start going
>> out for the images.

> Oh, right.  Yeah, w3m does seem ridiculously slow in fetching pictures.
> Perhaps I should peek at the w3m code instead.

It is just sitting there, doing nothing for ~10s. Then it looks like it
then runs w3m-idle-images-show() - I used toggle-debug-on-quit and
C-g'ed once in a while (XEmacs doing nothing), and then when I saw
requests going out in the ngrep-window, I C-g'ed and got this:

  Debugger entered--Lisp error: (quit)
    ("next_event_internal()" "[internal]")
    sit-for(0.1 t)
    w3m-idle-images-show()
    apply(w3m-idle-images-show nil)
    byte-code("..." [this-command inhibit-quit quit-flag match-data itimer current-itimer match-data ((store-match-data match-data)) nil itimer-uses-arguments apply itimer-function itimer-function-arguments last-event-time next-wakeup itimers time-elapsed] 5)
    itimer-run-expired-timers(13.331835)
    itimer-timer-driver(nil)
    ("execute_internal_event()" "[internal]")
    (dispatch-event "[internal]")

> Meanwhile, has anybody written a handy "how to use git from within Emacs
> if you're used to cvs-update and vc-mode...  FOR DUMMIES"?

I think Magit is usually recommended, but it doesn't work in XEmacs, so
I haven't used it, and can't give any directions...

> I managed to check out the Gnus repository with password and stuff, but
> I'm not able to find out what magical keys to push to check stuff in
> again.  (Yeah, I know, it's probably "push" in git parlance.  But I'm
> covering my ears.  LA LA LA LA LA.  I can't hear you.  LA LA LA.)

The really short command-line version:

 git status             ; lists the changes (shows hints on how to change status of things as well)
 git add [file]         ; add to list of things to commit
 git commit -v          ; commits the files you have added for commiting, locally
 git push origin master ; push the commits you have made locally, out to the repository

Also:

 git log         ; to see the local commit log
 git show [sha1] ; to see what a commit consists of


  Best regards,

     Adam

-- 
 "Angels can fly because they take themselves lightly."       Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Async pre-treatment of articles

[Adam Sjøgren]

On Sat, 28 Aug 2010 22:55:55 +0200, Adam wrote:

> It is just sitting there, doing nothing for ~10s. Then it looks like it
> then runs w3m-idle-images-show()

Random grepping let me to try this:

  (setq w3m-image-no-idle-timer t)

Which seems to make quite a difference.


  Best regards,

    Adam

-- 
 "Angels can fly because they take themselves lightly."       Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Async pre-treatment of articles

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> Random grepping let me to try this:
>
>   (setq w3m-image-no-idle-timer t)
>
> Which seems to make quite a difference.

Hm.  My w3m has that set to nil, but it starts loading the picture
immediately, anyway, I think.  As far as I can tell...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Async pre-treatment of articles

[Adam Sjøgren]

On Sat, 28 Aug 2010 23:18:36 +0200, Lars wrote:

> asjo@koldfront.dk (Adam Sjøgren) writes:

>> (setq w3m-image-no-idle-timer t)

> Hm.  My w3m has that set to nil, but it starts loading the picture
> immediately, anyway, I think.  As far as I can tell...

When I changed w3m-image-no-idle-timer to t it made a world of
difference here.

ngrep shows that the images are requested as soon as the text is
displayed in the Article buffer, and the images show up quickly (as in
almost instantly).


  Best regards,

     Adam, who hasn't tried in GNU Emacs.

-- 
 "Angels can fly because they take themselves lightly."       Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Async pre-treatment of articles

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> ngrep shows that the images are requested as soon as the text is
> displayed in the Article buffer, and the images show up quickly (as in
> almost instantly).

Yes, but I want totally instantly.  As what you get when you read an
article the second time.  :-)

I've sent a query to the emacs-w3m list.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Async pre-treatment of articles

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

>  git push origin master ; push the commits you have made locally, out to the r

Hey!  That did the trick.

vc-mode in Emacs 23 works fine, it turns out.  I just mark the files and
check in as usual.  And then I did the "push" thing magically, and this
turned up on the cvs list, so it must be working:

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 8160f7a..40576a5 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,7 @@
+2010-08-28  Lars Magne Ingebrigtsen  <larsi@gnus.org>
+
+	* nntp.el (nntp-async-kluge): Remove the Emacs 20.3-related kluge. 
+


-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Async pre-treatment of articles

[Adam Sjøgren]

On Sat, 28 Aug 2010 23:28:59 +0200, Lars wrote:

> asjo@koldfront.dk (Adam Sjøgren) writes:

>> ngrep shows that the images are requested as soon as the text is
>> displayed in the Article buffer, and the images show up quickly (as in
>> almost instantly).

> Yes, but I want totally instantly.  As what you get when you read an
> article the second time.  :-)

I was coming from "sometimes the images show up when I wait for a, to
me, mysterious number of seconds", so the improvement was huge.

I just tried GNU Emacs, and apparantly setting that variable to t is not
necessary there; and I see the small delay you're talking about.


  Best regards,

    Adam

-- 
 "The success of open source code is perhaps the only         Adam Sjøgren
  thing in the computer field that hasn't surprised me   asjo@koldfront.dk
  during the past several decades."

Re: Async pre-treatment of articles

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Meanwhile, has anybody written a handy "how to use git from within
> Emacs if you're used to cvs-update and vc-mode...  FOR DUMMIES"?

vc-mode should work as usual (at least from emacs23 on.  Possibly 22 as
well).

But where `C-x v v' actually checks in stuff is a bit of a mystery to
me.  That is: I know it checks it into the local repo, but if it checks
it in into the same branch everybody else works on, or if it checks it
into a user-specific branch, I don't know.

(And I really would like to know, because I have a feeling that these
new distributed version control systems are really powerful... if I
could understand them...)

Re: Async pre-treatment of articles

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> +2010-08-28  Lars Magne Ingebrigtsen  <larsi@gnus.org>
> +
> +	* nntp.el (nntp-async-kluge): Remove the Emacs 20.3-related kluge. 
> +

Was the speling of "kluge" intentional?

Re: Async pre-treatment of articles

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Was the speling of "kluge" intentional?

I can't recall.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Async pre-treatment of articles

[Adam Sjøgren]

On Sun, 29 Aug 2010 01:54:32 +0200, Steinar wrote:

>>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

>> +2010-08-28  Lars Magne Ingebrigtsen  <larsi@gnus.org>

>> +	* nntp.el (nntp-async-kluge): Remove the Emacs 20.3-related kluge. 

> Was the speling of "kluge" intentional?

Both spellings are used:

 * http://catb.org/jargon/html/K/kludge.html
   http://catb.org/jargon/html/K/kluge.html

 * http://www.merriam-webster.com/dictionary/kluge

 * http://en.wikipedia.org/wiki/Kludge


  :-),

   Adam

-- 
 "Didn't matter to me what I said. Still doesn't,             Adam Sjøgren
  really."                                               asjo@koldfront.dk