Gnus development mailing list
 help / color / mirror / Atom feed
* minor nit with pgnus mail-fetching
@ 1999-07-27  2:20 Justin Sheehy
  1999-07-27  8:21 ` Hrvoje Niksic
  0 siblings, 1 reply; 2+ messages in thread
From: Justin Sheehy @ 1999-07-27  2:20 UTC (permalink / raw)


I've probably explained my mail-handling process here before a couple
of times, but I'll do so again for background.

I filter via procmail into spools in ~/Mail/incoming, one per nnml
group.  For various reasons, this suits my needs better than using
Gnus splitting.

One thing that I do quite frequently is M-g over a given mail group.
An advantage of my mail setup in this situation is that it does not
have to process any mail for groups other than the one I am interested 
in.

My nnmail-spool-file is   `((directory :path 
                             ,(expand-file-name "~/Mail/incoming")
                             :suffix ""))

If I M-g over a group that does have new mail, Gnus acts as expected:

nnml: Reading incoming mail from directory...
Wrote blah/blah/43
Wrote blah/blah/44
Wrote blah/blah/45
nnml: Reading incoming mail (3 new)...done

However, if I M-g over a group with no new mail, Gnus simply says:

nnml: Reading incoming mail from directory... 

and never says "done" or "no news" or even erases the message.  Thus,
one does not immediately know if it is taking Gnus a long time to
access the file or if there is in fact no mail there.

This is suboptimal behavior.  I've taken a quick look at the relevant
code, but I do not have the time to invesitgate as deeply as I would like.

-Justin

 


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: minor nit with pgnus mail-fetching
  1999-07-27  2:20 minor nit with pgnus mail-fetching Justin Sheehy
@ 1999-07-27  8:21 ` Hrvoje Niksic
  0 siblings, 0 replies; 2+ messages in thread
From: Hrvoje Niksic @ 1999-07-27  8:21 UTC (permalink / raw)


Justin Sheehy <dworkin@ccs.neu.edu> writes:

> nnml: Reading incoming mail from directory... 
> 
> and never says "done" or "no news" or even erases the message.  Thus,
> one does not immediately know if it is taking Gnus a long time to
> access the file or if there is in fact no mail there.
> 
> This is suboptimal behavior.

How about this quickie patch:

--- nnmail.el.orig	Tue Jul 27 10:15:06 1999
+++ nnmail.el	Tue Jul 27 10:19:16 1999
@@ -1447,7 +1447,9 @@
 	    (incf total new)
 	    (incf i))))
       ;; If we did indeed read any incoming spools, we save all info.
-      (unless (zerop total)
+      (if (zerop total)
+	  (nnheader-message 4 "%s: Reading incoming mail (no new mail)...done"
+			    method (car source))
 	(nnmail-save-active
 	 (nnmail-get-value "%s-group-alist" method)
 	 (nnmail-get-value "%s-active-file" method))

You can also try replacing the nnheader-message thing with something
that just clears the echo area instead of cluttering it and see if
that which one works out better.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1999-07-27  8:21 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-07-27  2:20 minor nit with pgnus mail-fetching Justin Sheehy
1999-07-27  8:21 ` Hrvoje Niksic

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).