Re: No Gnus todo item

[Simon Josefsson <jas@extundo.com>]

Ted Zlatanov <tzz@lifelogs.com> writes:

>>> May I suggest either a variable like gnus-startup-without-scan or a
>>> function gnus-fast?  The function seems the better solution.  You
>>> startup gnus with emacs -f gnus-fast and then `g' is still bound to
>>> the gnus function so things work like they always have.
>>>
>>> In fact, it seems like the gnus function already has a dont-connect
>>> parameter.  Is that not useful?
>> 
>> It is, and it may be tested by using M-x gnus-no-server RET or M-x
>> gnus-unplugged RET depending on preference.  I'm talking about the
>> default behavior.
>> 
>> Perhaps the idea doesn't make sense unless the asynchronous update
>> of read counts is implemented.  If so, the consider that implemented
>> too, when thinking about the feature.
>
> I think we'd need asynchronous mail fetching and article count
> updates to do what you want.  It's a very good goal, but it might
> require a major rewrite of Gnus.

I don't think it is requires much work, it should be possible to do
even without touching existing code, I think.

A somewhat IMAP specific incarnation of this idea would run a function
via the idle timer, have it pick one group, send off a few commands to
the server to request information, and return.  Takes a few
milliseconds, max.  When it is invoked the next time, it looks if it
has received outstanding requests, if so, it parses them and frob a
few Gnus data structure, redraws one line of the group buffer, and
returns.  This goes on until all groups are updated.

I would agree that doing this for mail-sources and client-side
filtering is harder, but the above approach should work for nnml,
nnfolder, nntp, nnmaildir and nnimap.