Gnus development mailing list
 help / color / mirror / Atom feed
From: Simon Josefsson <jas@pdc.kth.se>
Subject: Re: has "incorporating new mail" bug been fixed yet?
Date: 25 Dec 1999 00:46:19 +0100	[thread overview]
Message-ID: <ilu1z8bucl0.fsf@badis.pdc.kth.se> (raw)
In-Reply-To: dsg@mitre.org's message of "23 Dec 1999 15:39:21 -0500"

David S. Goldberg <dsg@mitre.org> 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))))
 



      parent reply	other threads:[~1999-12-24 23:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-12-23 17:51 Randal L. Schwartz
1999-12-23 18:23 ` David S. Goldberg
1999-12-23 20:16   ` Randal L. Schwartz
1999-12-23 18:39 ` Bud Rogers
1999-12-23 20:18   ` Randal L. Schwartz
1999-12-23 20:39     ` Bud Rogers
1999-12-23 20:39     ` David S. Goldberg
1999-12-24  6:15       ` Randal L. Schwartz
1999-12-24 23:46       ` Simon Josefsson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ilu1z8bucl0.fsf@badis.pdc.kth.se \
    --to=jas@pdc.kth.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).