Re: Gnus vs Wanderlust

[colin.rafferty@morganstanley.com]

Miles Bader wrote:
> colin.rafferty@morganstanley.com writes:

>> I love Gnus as a news reader.  I use it actively, and think it is the
>> best news reader ever.  However, the needs of a mail reader are
>> different from a news reader.

> I've always thought this was a very silly argument.  I also find that I
> have slightly different preferences for mail and news, but the amount of
> _shared_ behavior is _huge_.  

I think that from the implementation side, the shared behavior is
huge, but on the user end, for me at least, I approach reading mail
and reading news very differently.

> It seems bizarre to say "Oh just implement a completely new system!"
> instead of just fixing the problems with Gnus.

That's the advantage of just being a user.

> the main problem I've had seems to be the same that you mention: it
> deals poorly with sparse article ranges.  Fixing this would go a
> _long_ way towards making it perfect for me.

Having written, and then reread my own article, I've really thought
about why it is that I'm not using Gnus for mail, given that I have a
imap server.

I realize that I agree with you.  The only true problem is Summary
generation.  Everything else is configurable.

So how can we fix this?

I have 707 messages in a range of 15382 on my imap server.  I don't
care that the first time I ever read this takes 45 seconds to load.
That's 15 seconds to get the headers from the server, and 30 seconds
to generate the summary.

What I care about is if I receive one more message, while it has
cached the information about the previous 707 messages, so the server
download is negligible, it still takes 30 seconds to regenerate a
summary that is being trivially changed.

There are two basic problems with how Gnus does this:

1. It does not cache summary layout information.  When it builds a
   summary, it has to start from scratch.  WL always caches, and VM is
   optionally able to cache.

2. Its method of reloading a group is to tear down the summary and lay
   it out again, rather than applying a delta.  WL and VM both use
   deltas, so updates are immediate.

Both of these choices make a lot of sense for newsgroups, since in
general, what was in the summary before has already been read, and the
user won't be interested in it again.  However, with regular mail, you
want to see everything, so it doesn't make sense.

So what we need is options that allow us to fix those two problems:

1. Optionally allow for caching of the summary, so it can quickly be
   rebuilt.

2. Optionally allow M-g to apply deltas rather than tear-down and
   build-up.

Note that if we implement item 1, then item 2 becomes less necessary.

-- 
Colin