From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/56739 Path: main.gmane.org!not-for-mail From: David Hanak Newsgroups: gmane.emacs.gnus.general Subject: Re: Exact article count for nnml groups Date: Mon, 15 Mar 2004 11:03:20 -0600 Organization: Institute for Software Integrated Systems, Vanderbilt University Sender: ding-owner@lists.math.uh.edu Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1079370267 14318 80.91.224.253 (15 Mar 2004 17:04:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 15 Mar 2004 17:04:27 +0000 (UTC) Original-X-From: ding-owner+M5278@lists.math.uh.edu Mon Mar 15 18:04:16 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B2vVg-0000HV-00 for ; Mon, 15 Mar 2004 18:04:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1B2vUu-0000ZJ-00; Mon, 15 Mar 2004 11:03:28 -0600 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1B2vUp-0000ZE-00 for ding@lists.math.uh.edu; Mon, 15 Mar 2004 11:03:23 -0600 Original-Received: from quimby.gnus.org (quimby.gnus.org [80.91.224.244]) by justine.libertine.org (Postfix) with ESMTP id B94303A003B for ; Mon, 15 Mar 2004 11:03:22 -0600 (CST) Original-Received: from news by quimby.gnus.org with local (Exim 3.35 #1 (Debian)) id 1B2vUn-0006gI-00 for ; Mon, 15 Mar 2004 18:03:21 +0100 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 97 Original-NNTP-Posting-Host: a139106.n1.vanderbilt.edu Original-X-Trace: quimby.gnus.org 1079370201 25685 129.59.139.106 (15 Mar 2004 17:03:21 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: Mon, 15 Mar 2004 17:03:21 +0000 (UTC) User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:anzVsPUaEuF1ktpWiyLDY4dH/gk= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:56739 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:56739 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 > . 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