From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/28451 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: has "incorporating new mail" bug been fixed yet? Date: 25 Dec 1999 00:46:19 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: References: <87iu1p1oyx.fsf@twocups.sirinet.net> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035165296 29927 80.91.224.250 (21 Oct 2002 01:54:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 01:54:56 +0000 (UTC) Return-Path: Original-Received: from spinoza.math.uh.edu (spinoza.math.uh.edu [129.7.128.18]) by mailhost.sclp.com (Postfix) with ESMTP id 5998FD0529 for ; Fri, 24 Dec 1999 20:19:58 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by spinoza.math.uh.edu (8.9.1/8.9.1) with ESMTP id TAB22666; Fri, 24 Dec 1999 19:16:21 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 24 Dec 1999 19:15:33 -0600 (CST) Original-Received: from mailhost.sclp.com (postfix@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id TAA24386 for ; Fri, 24 Dec 1999 19:15:21 -0600 (CST) Original-Received: from badis.pdc.kth.se (badis.pdc.kth.se [130.237.221.45]) by mailhost.sclp.com (Postfix) with ESMTP id 0FEC7D0529 for ; Fri, 24 Dec 1999 20:13:41 -0500 (EST) Original-Received: (from jas@localhost) by badis.pdc.kth.se (8.9.3/8.9.3) id CAA06188; Sat, 25 Dec 1999 02:13:39 +0100 X-Authentication-Warning: badis.pdc.kth.se: jas set sender to jas@pdc.kth.se using -f Original-To: The Gnus Mailing List In-Reply-To: dsg@mitre.org's message of "23 Dec 1999 15:39:21 -0500" Original-Lines: 103 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:28451 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:28451 David S. Goldberg writes: > As you note, the problem is due to using a directory source, but it's > not the case that the existence of 50-some .spool files causes the > problem. The problem is that you've got 50-some nnml groups at levels > 1 and 2 and the directory is being searched for a file for each one, > whether or not such a file exists. Right. > This is apparently (to me, based on the explanation I only vaguely > recall from Simon) due to nnml not having a particular feature in > the nnml-request-scan function. Actually, it's because nnml don't have `nnml-retrieve-groups', but that's not relevant -- writing a `nnfoo-retrieve-groups' is only useful if the backend is slow on doing `nnfoo-request-group' which isn't the case for nnml (it was for nnimap though), and it's not what's causing theese messages. The annoying messages are a result of how the `directory' mail-source work. "Normal" mail-sources (that is, all other mail-sources than `directory') get queried once when you fetch new mail. For `directory' mail-sources, there's a hack in `nnmail-get-new-mail' which change the mail-source for every group you fetch new mail in. I haven't really used directory mail-sources, but I believe the hack is there to make directory mail-sources work as expected, which would be to make mail in file "foo" should end up in nnml group "foo" and nowhere else. This means that instead of having 1 mail-source for your n nnml groups which one could be led into believing when looking at `mail-sources' you have in fact n mail-sources, one for each of your n nnml groups, and the thing you write in your `mail-sources' is a template that is expanded to the correct mail-source at run-time. When you do `1 g' to get new mail for some of your nnml groups, you'll get one message for every mail-source that is being queried. If you have 10 nnml groups on level 1, there will be 10 different mail-sources queried for new mail. And you'll get 10 messages about there being none (or some, or whatever) mail fetched from that mail-source. I believe this discussion came up recently, just after my speed-up patch for scanning mail-sources only once. Since that patch really shouldn't change any underlaying behaviour, something might be wrong with it. I reverted to PGnus 0.99 (which is before my patch was introduced) and I was able to reproduce the behaviour Randal describes. Randal (and other directory mail-source users), when did you start seeing this behaviour? Recently? Was it introduced with PGnus 0.99? If not, I think this is how it's supposed to work. You get one message for each of your mail-source, and that will help you to debug things if one of the n fetches failed. This (untested) patch change the verbosity level on some of the related messages, it should make the "annoying" messages go away. I don't think this should be commited as-is (or at all), maybe the verbosity level should be different for `directory' mail-sources and other mail-sources? That isn't very clean either. Index: nnmail.el =================================================================== RCS file: /usr/local/cvsroot/gnus/lisp/nnmail.el,v retrieving revision 5.44 diff -w -u -u -w -r5.44 nnmail.el --- nnmail.el 1999/12/07 05:09:43 5.44 +++ nnmail.el 1999/12/25 01:09:11 @@ -1444,7 +1444,7 @@ ;; The we go through all the existing mail source specification ;; and fetch the mail from each. (while (setq source (pop fetching-sources)) - (nnheader-message 4 "%s: Reading incoming mail from %s..." + (nnheader-message 8 "%s: Reading incoming mail from %s..." method (car source)) (when (setq new (mail-source-fetch @@ -1458,19 +1458,18 @@ (incf total new) (incf i))) ;; If we did indeed read any incoming spools, we save all info. - (if (zerop total) - (nnheader-message 4 "%s: Reading incoming mail (no new mail)...done" - method (car source)) + (unless (zerop total) (nnmail-save-active (nnmail-get-value "%s-group-alist" method) (nnmail-get-value "%s-active-file" method)) (when exit-func (funcall exit-func)) (run-hooks 'nnmail-read-incoming-hook) - (nnheader-message 4 "%s: Reading incoming mail (%d new)...done" method - total)) + (nnheader-message 4 "%s: Read %d new mail from %s." method total + (car source))) ;; Close the message-id cache. (nnmail-cache-close) + (nnheader-message 8 "%s: Reading incoming mail...done" method total) ;; Allow the user to hook. (run-hooks 'nnmail-post-get-new-mail-hook))))