Re: Exact article count for nnml groups

[David Hanak <dhanak@isis.vanderbilt.edu>]

Jesper, Kevin, Kai,

thanks for your verbose replies and comments.  I wish I had time to work on
the "project"...  This whole thing started out as a very simple
modification to display exact article count for my nnml groups, and then I
thought why couldn't others profit from it, too.  I never planned to spend
this much time with it, though.

In short, I will try to incorporate your suggestions when I get to it.  For
more thoughts, read on.

On Fri, 12 Mar 2004, Jesper Harder wrote:

> If possible try to follow the style guide for docstrings in
> <info://elisp/Documentation+Tips>.

I will.

>> +   (condition-case ()
>
> It's harder to debug code inside `condition-case'.  It's better if you
> can restrict to just the form(s) that you know might signal an error
> (and you know that the error can safely be ignored, of course).

I think I copied this part from somewhere else in the Gnus code, but I
don't really remember the details.  Anyway, I will try to follow your
advice. 

>> + 	(delete-region (point) (line-end-position))
>
> You need to use `point-at-bol' to be compatible with XEmacs.

Grin.  I've never used XEmacs, let alone program it.


On Fri, 12 Mar 2004, Kevin Greiner wrote:

> * I'm not really happy with the use of a regexp to select groups.
>   Your gnus-get-group-articles-list is making calls to the backend
>   (i.e. server-specific code).  Shouldn't the on/off switch be in the
>   server's method?

If I only knew anything about servers and server variables in practice. :-)
But I will try to think of a better way...

> * The previous points had me looking in gnus-int where I found
>   gnus-request-group-articles.  Your new backend
>   'get-group-articles-list is simply the existing
>   'request-group-articles returning the articles as a list rather than
>   in a buffer.  From looking at your implementation, I can see why you
>   want to do this as it certainly optimizes the API for nnml.

:-))  We had the very same discussion with Kai last June, when the patch
was developed.  It was he who pointed me out the request-group-articles
server methods, and IIRC, it was he who suggested that if I'm unsatisfied
with the performance, than it should be used as a fallback function to a
quicker, more direct one, thus get-group-articles-list was created.

>   start a separate thread to discuss updating 'request-group-articles to
>   return a list rather than a buffer.

I don't think that would be good.  It would break the rule that request
functions always manipulate the server buffer, and never return their
results directly.

> * From what I can see, there's only one call to your new code and
>   that's in gnus-articles-to-read.  Are you sure that this one
>   function in gnus-sum is all that is necessary to change the article
>   counts in the GROUP buffer? Also, which article count are you trying
>   to correct? By my reading, the group buffer can display eight
>   different counts for each group.

Eight?  Wow, I'm impressed.  Ok, it is the count shown by the %y formatter,
AND the count respected by the test which checks group size before entering
a group and optionally asks for the number of articles to be requested.
I'm pretty sure it works, since I've been using the same patch for two
years now, and I never had any problems.

On Sat, 13 Mar 2004, Kai Grossjohann wrote:

> It's good stuff.

If it is, it's your influence! :-)

> I'd suggest to do away with the gnus-count-articles-in-groups variable
> -- just always try to invoke the new function if available.

What if someone wants to turn this functionality off, say, because he/she
has a slow machine, or when someone implements the required funciton for
nnimap, too, which can be really slow for bad IMAP connections?  I think we
need some way to control it other than the mere existence of the required
functions.

Thanks,

-- 
David