`new' indicator for nnimap groups?

`new' indicator for nnimap groups?

[Kai Großjohann]

I've recently invoked mutt for my IMAP inbox.  It displayed `N' in
front of messages I'd never looked at.  Is this possible with Gnus,
too?  How?

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I've recently invoked mutt for my IMAP inbox.  It displayed `N' in
> front of messages I'd never looked at.  Is this possible with Gnus,
> too?  How?

Messages or groups?  With groups, N on a subscribed groups would
translate into a non-zero unread count, and on non-subscribed groups I
think you would need to make Gnus discover new groups and highlight
them somehow.  Zombies?  I'm not sure.  With messages, isn't N the
same as an unread article (marked as such by Gnus)?  Maybe I should
test Mutt..

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

On Sat, 28 Jul 2001, Simon Josefsson wrote:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
>> I've recently invoked mutt for my IMAP inbox.  It displayed `N' in
>> front of messages I'd never looked at.  Is this possible with Gnus,
>> too?  How?
> 
> Messages or groups?  With groups, N on a subscribed groups would
> translate into a non-zero unread count, and on non-subscribed groups
> I think you would need to make Gnus discover new groups and
> highlight them somehow.  Zombies?  I'm not sure.

No, no.  I wasn't talking about an indicator for groups, but while
we're at it, the one for nnimap should work just like the normal %m
specifier for gnus-group-line-format.  I'm using that, and before my
recent switch to IMAP it indicated whether a group had received any
new mail during the current session.  (It looked at the result of
splitting, I think.)

> With messages, isn't N the same as an unread article (marked as such
> by Gnus)?  Maybe I should test Mutt..

No.  I had some unread articles in my nnimap:INBOX.  They arrived
there as fresh messages, then I read them, but then I hit `M-u'.  And
two articles arrived in the past five minutes or so so I had never
looked at them at all.

It seems mutt was able to distinguish between the ones that were
_really_ new versus the ones where I used `M-u'.

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Amos Gouaux]

>>>>> On Sat, 28 Jul 2001 18:18:56 +0200,
>>>>> Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> (kg) writes:

kg> It seems mutt was able to distinguish between the ones that were
kg> _really_ new versus the ones where I used `M-u'.

Oh, I think I know what you mean.  I can't remember which client it
was, but I do remember one that would distinguish between 'New' and
'Unread'.  Hmmm....

I think if the 'Status:' header is 'R', then the message shows up as
read.  If it is 'O', then it shows up as 'Unread'.  If it doesn't
exist at all, then it is 'New'.  I think that's right.  Can't
remember where I saw that from.....

-- 
Amos

Re: `new' indicator for nnimap groups?

[Karl Kleinpaste]

Amos Gouaux <amos+lists.ding@utdallas.edu> writes:
> I can't remember which client it was, but I do remember one that
> would distinguish between 'New' and 'Unread'.  Hmmm....

Plain, old, ancient, crufty, prehistoric Berkeley Mail did that.

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

On Sat, 28 Jul 2001, Amos Gouaux wrote:

> I think if the 'Status:' header is 'R', then the message shows up as
> read.  If it is 'O', then it shows up as 'Unread'.  If it doesn't
> exist at all, then it is 'New'.  I think that's right.  Can't
> remember where I saw that from.....

Does nnimap frob that header?  Or the IMAP server, perhaps?  Remember,
this was about IMAP...

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> On Sat, 28 Jul 2001, Amos Gouaux wrote:
> 
>> I think if the 'Status:' header is 'R', then the message shows up as
>> read.  If it is 'O', then it shows up as 'Unread'.  If it doesn't
>> exist at all, then it is 'New'.  I think that's right.  Can't
>> remember where I saw that from.....
> 
> Does nnimap frob that header?  Or the IMAP server, perhaps?  Remember,
> this was about IMAP...

At least the UoW IMAP server read/writes that header for backwards
compatibility reasons.  Gnus nnmail.el and nnml.el seem to have some
code to handle this header, but they are never invoked AFAICT.  The
IMAP stuff certainly doesn't use it.

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

>> With messages, isn't N the same as an unread article (marked as such
>> by Gnus)?  Maybe I should test Mutt..
> 
> No.  I had some unread articles in my nnimap:INBOX.  They arrived
> there as fresh messages, then I read them, but then I hit `M-u'.  And
> two articles arrived in the past five minutes or so so I had never
> looked at them at all.
> 
> It seems mutt was able to distinguish between the ones that were
> _really_ new versus the ones where I used `M-u'.

Aha.  That translates into the \Recent flag in IMAP.  I added a
secondary flag "recent" to my Gnus but I found it quite useless -- the
\Recent flag in IMAP is defined to only be present on articles the
first time a mailbox is selected with the new messages.  Gnus/nnimap
often (re-)selects mailboxes so you'll never see the mark in the
real-world -- \Recent will be gone once the summary buffer is about to
be generated.

But something similar could perhaps be useful.

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

On Sun, 29 Jul 2001, Simon Josefsson wrote:

> Aha.  That translates into the \Recent flag in IMAP.  I added a
> secondary flag "recent" to my Gnus but I found it quite useless --
> the \Recent flag in IMAP is defined to only be present on articles
> the first time a mailbox is selected with the new messages.
> Gnus/nnimap often (re-)selects mailboxes so you'll never see the
> mark in the real-world -- \Recent will be gone once the summary
> buffer is about to be generated.

Hm.  I see.  Hm.  Of course, the next obvious question is why does
Gnus/nnimap reselect the group so often and can be superfluous times
be optimized away?

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

>> Aha.  That translates into the \Recent flag in IMAP.  I added a
>> secondary flag "recent" to my Gnus but I found it quite useless --
>> the \Recent flag in IMAP is defined to only be present on articles
>> the first time a mailbox is selected with the new messages.
>> Gnus/nnimap often (re-)selects mailboxes so you'll never see the
>> mark in the real-world -- \Recent will be gone once the summary
>> buffer is about to be generated.
> 
> Hm.  I see.  Hm.  Of course, the next obvious question is why does
> Gnus/nnimap reselect the group so often and can be superfluous times
> be optimized away?

When you `g' Gnus select each mailbox and search for highest/lowest
article, so after that all \Recent's are gone.  Also, when entering a
group, it selects, unselects and selects the mailbox to workaround a
bug in some servers (see `nnimap-before-find-minmax-bugworkaround').

The first one could be fixed by Gnus understanding the
number-of-unread-articles value instead of calculating that itself
using highest/lowest article number.  The second is trickier.  Perhaps
it should be conditional on a variable you can enable if your server
is buggy.

There might be other less common cases as well...

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

On Sun, 29 Jul 2001, Simon Josefsson wrote:

> The first one could be fixed by Gnus understanding the
> number-of-unread-articles value instead of calculating that itself
> using highest/lowest article number.

Gnus can already add extra info to the .overview files.  Maybe an
analogous extension to another format (the active file format?) could
be used for some backends to report the real number of unread articles
to Gnus.

I wish I had the time...

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

On Sun, 29 Jul 2001, Kai Großjohann wrote:

> On Sun, 29 Jul 2001, Simon Josefsson wrote:
>
> > The first one could be fixed by Gnus understanding the
> > number-of-unread-articles value instead of calculating that itself
> > using highest/lowest article number.
>
> Gnus can already add extra info to the .overview files.  Maybe an
> analogous extension to another format (the active file format?) could
> be used for some backends to report the real number of unread articles
> to Gnus.

The field is already present -- but Gnus does not use it.  It wouldn't be
difficult to make Gnus start using the field, but I think it's harder to
make Gnus stop using the highest/lowest article number.  Perhaps it's
not that hard.

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

On Mon, 30 Jul 2001, Simon Josefsson wrote:

> The field is already present -- but Gnus does not use it.  It
> wouldn't be difficult to make Gnus start using the field, but I
> think it's harder to make Gnus stop using the highest/lowest article
> number.  Perhaps it's not that hard.

Hm.  Maybe it can be done in steps?  First, change the number
displayed for %y (and friends) in gnus-group-line-format.  Then,
change the number used in the comparison with gnus-large-newsgroup.
And then, I think, you're done.  No?

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

On Mon, 30 Jul 2001, Kai Großjohann wrote:

> On Mon, 30 Jul 2001, Simon Josefsson wrote:
>
> > The field is already present -- but Gnus does not use it.  It
> > wouldn't be difficult to make Gnus start using the field, but I
> > think it's harder to make Gnus stop using the highest/lowest article
> > number.  Perhaps it's not that hard.
>
> Hm.  Maybe it can be done in steps?  First, change the number
> displayed for %y (and friends) in gnus-group-line-format.  Then,
> change the number used in the comparison with gnus-large-newsgroup.
> And then, I think, you're done.  No?

No, the tricky part is to update the read article range for the group, you
can't do that with simply the number of read articles (since articles may
have been expired).  OTOH, perhaps you could delay the updating until the user
try to enter the group.

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

On Thu, 2 Aug 2001, Simon Josefsson wrote:

> No, the tricky part is to update the read article range for the
> group, you can't do that with simply the number of read articles
> (since articles may have been expired).  OTOH, perhaps you could
> delay the updating until the user try to enter the group.

The read range doesn't have to change, does it?  If it works fine now,
why should it fail later?

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

On Thu, 2 Aug 2001, Kai Großjohann wrote:

> > No, the tricky part is to update the read article range for the
> > group, you can't do that with simply the number of read articles
> > (since articles may have been expired).  OTOH, perhaps you could
> > delay the updating until the user try to enter the group.
>
> The read range doesn't have to change, does it?  If it works fine now,
> why should it fail later?

Hmm.  Ah, yes, I meant the active range.  If you only have the currently
highest/lowest article number, and get an updated count of articles in
the mailbox, how do you know which articles exists in the mailbox?  So
Gnus doesn't know which articles to request from the backend when entering
the group, unless it knows the highest/lowest article number.  But still,
this decision could be delayed from `g' to when you actually enter the
group to speed things up. The backend interface probably needs to change
for this, though.

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

On Thu, 2 Aug 2001, Simon Josefsson wrote:

> Hmm.  Ah, yes, I meant the active range.  If you only have the
> currently highest/lowest article number, and get an updated count of
> articles in the mailbox, how do you know which articles exists in
> the mailbox?  So Gnus doesn't know which articles to request from
> the backend when entering the group, unless it knows the
> highest/lowest article number.  But still, this decision could be
> delayed from `g' to when you actually enter the group to speed
> things up. The backend interface probably needs to change for this,
> though.

My suggest was to change the backend interface in such a way that some
backends report the number of unread messages _in addition to_ the
low/high numbers.  The rest of Gnus can continue to use the low/high
numbers as before, only the `draw the group buffer' code uses the
number of unread messages (if available).

I fail to see how Gnus could work less well when it has more
information?

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

On Thu, 2 Aug 2001, Kai Großjohann wrote:

> On Thu, 2 Aug 2001, Simon Josefsson wrote:
>
> > Hmm.  Ah, yes, I meant the active range.  If you only have the
> > currently highest/lowest article number, and get an updated count of
> > articles in the mailbox, how do you know which articles exists in
> > the mailbox?  So Gnus doesn't know which articles to request from
> > the backend when entering the group, unless it knows the
> > highest/lowest article number.  But still, this decision could be
> > delayed from `g' to when you actually enter the group to speed
> > things up. The backend interface probably needs to change for this,
> > though.
>
> My suggest was to change the backend interface in such a way that some
> backends report the number of unread messages _in addition to_ the
> low/high numbers.  The rest of Gnus can continue to use the low/high
> numbers as before, only the `draw the group buffer' code uses the
> number of unread messages (if available).
>
> I fail to see how Gnus could work less well when it has more
> information?

Ah, I thought we we're talking about how to optimize away the unnecessary
(re-)selecting of mailboxes to get the \Recent flag to be useful. To
get that to work, we can't have the old system still in place.  But yes,
it could be done in steps.

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

On Thu, 2 Aug 2001, Simon Josefsson wrote:

> Ah, I thought we we're talking about how to optimize away the
> unnecessary (re-)selecting of mailboxes to get the \Recent flag to
> be useful. To get that to work, we can't have the old system still
> in place.  But yes, it could be done in steps.

Oh, boy.  I think I was in the wrong thread.  This threads tree stuff
is no good -- it shows me a nice tree but I can't see the subject
anymore :-(

Argh.

Sorry.

Don't worry too much about this \Recent flag, though.  Lots of people
have been asking about a more correct unread count in the group buffer
and in the check against gnus-large-newsgroup.  So let's satisfy them.

Any takers?

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Amos Gouaux]

>>>>> On Sat, 28 Jul 2001 13:25:21 +0200,
>>>>> Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> (kg) writes:

kg> I've recently invoked mutt for my IMAP inbox.  It displayed `N' in
kg> front of messages I'd never looked at.  Is this possible with Gnus,
kg> too?  How?

Isn't that in a way implied if there are no other marks?

-- 
Amos

Re: `new' indicator for nnimap groups?

[Nuutti Kotivuori]

Kai Großjohann wrote:
> I've recently invoked mutt for my IMAP inbox.  It displayed `N' in
> front of messages I'd never looked at.  Is this possible with Gnus,
> too?  How?

,----[ RFC2060 ]
| \Recent
|
| Message is "recently" arrived in this mailbox.  This session is the
| first session to have been notified about this message; subsequent
| sessions will not see \Recent set for this message.  This flag can
| not be altered by the client.
| 
| If it is not possible to determine whether or not this session is
| the first session to be notified about a message, then that message
| SHOULD be considered recent.
| 
| If multiple connections have the same mailbox selected
| simultaneously, it is undefined which of these connections will see
| newly-arrives messages with \Recent set and which will see it
| without \Recent set.
`----

IMHO, the Recent functionality from the IMAP is pretty unusable, since
the message may go through whatever fetchmails and mail-sources and so
on.

But,

I think it would be nice if a _similar_ functionality would be in Gnus
- that messages that have not ever been displayed to the user before
(in the summary buffer) would be marked recent, and a subsequent entry
to the summary buffer would remove these marks.

But then again, I don't know if anyone would use it for anything.

-- Naked

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I've recently invoked mutt for my IMAP inbox.  It displayed `N' in
> front of messages I'd never looked at.  Is this possible with Gnus,
> too?  How?

I've been running with my "new" mark patch for a while, and altough it
isn't perfect I've actually found it useful.  So maybe you'd like to
test it.

Index: gnus.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus.el,v
retrieving revision 6.39
diff -u -u -w -u -w -r6.39 gnus.el
--- gnus.el	2001/08/03 04:53:52	6.39
+++ gnus.el	2001/08/05 13:12:13
@@ -1787,7 +1787,8 @@
     (bookmarks . bookmark) (dormant . dormant)
     (scored . score) (saved . save)
     (cached . cache) (downloadable . download)
-    (unsendable . unsend) (forwarded . forward)))
+    (unsendable . unsend) (forwarded . forward)
+    (recent . recent)))
 
 (defvar gnus-headers-retrieved-by nil)
 (defvar gnus-article-reply nil)
Index: gnus-sum.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-sum.el,v
retrieving revision 6.85
diff -u -u -w -u -w -r6.85 gnus-sum.el
--- gnus-sum.el	2001/07/28 22:57:50	6.85
+++ gnus-sum.el	2001/08/05 13:12:27
@@ -439,6 +439,11 @@
   :group 'gnus-summary-marks
   :type 'character)
 
+(defcustom gnus-recent-mark ?N
+  "*Mark used for articles that are recent."
+  :group 'gnus-summary-marks
+  :type 'character)
+
 (defcustom gnus-cached-mark ?*
   "*Mark used for articles that are in the cache."
   :group 'gnus-summary-marks
@@ -1147,6 +1152,9 @@
 (defvar gnus-newsgroup-forwarded nil
   "List of articles that have been forwarded in the current newsgroup.")
 
+(defvar gnus-newsgroup-recent nil
+  "List of articles that have are recent in the current newsgroup.")
+
 (defvar gnus-newsgroup-expirable nil
   "List of articles in the current newsgroup that can be expired.")
 
@@ -1205,6 +1213,7 @@
     gnus-newsgroup-unselected gnus-newsgroup-marked
     gnus-newsgroup-reads gnus-newsgroup-saved
     gnus-newsgroup-replied gnus-newsgroup-forwarded
+    gnus-newsgroup-recent
     gnus-newsgroup-expirable
     gnus-newsgroup-processable gnus-newsgroup-killed
     gnus-newsgroup-downloadable gnus-newsgroup-undownloaded
@@ -4320,6 +4329,8 @@
 		    gnus-forwarded-mark)
 		   ((memq number gnus-newsgroup-saved)
 		    gnus-saved-mark)
+		   ((memq number gnus-newsgroup-recent)
+		    gnus-recent-mark)
 		   (t gnus-no-mark))
 	     gnus-tmp-from (mail-header-from gnus-tmp-header)
 	     gnus-tmp-name
@@ -8584,7 +8595,7 @@
 	(error "No such mark type: %s" type)
       (setq var (intern (format "gnus-newsgroup-%s" type)))
       (set var (cons article (symbol-value var)))
-      (if (memq type '(processable cached replied forwarded saved))
+      (if (memq type '(processable cached replied forwarded recent saved))
 	  (gnus-summary-update-secondary-mark article)
 	;;; !!! This is bobus.  We should find out what primary
 	;;; !!! mark we want to set.
@@ -8844,6 +8855,8 @@
 	  gnus-forwarded-mark)
 	 ((memq article gnus-newsgroup-saved)
 	  gnus-saved-mark)
+	 ((memq article gnus-newsgroup-recent)
+	  gnus-recent-mark)
 	 (t gnus-no-mark))
    'replied)
   (when (gnus-visual-p 'summary-highlight 'highlight)

Index: nnimap.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/nnimap.el,v
retrieving revision 6.12
diff -u -u -w -u -w -r6.12 nnimap.el
--- nnimap.el	2001/07/27 01:29:36	6.12
+++ nnimap.el	2001/08/05 13:13:13
@@ -902,9 +902,10 @@
 	    (gnus-info-set-read info seen)))
 
 	(mapcar (lambda (pred)
-		  (when (and (nnimap-mark-permanent-p (cdr pred))
+		  (when (or (eq (cdr pred) 'recent)
+			    (and (nnimap-mark-permanent-p (cdr pred))
 			     (member (nnimap-mark-to-flag (cdr pred))
-				     (imap-mailbox-get 'flags)))
+					 (imap-mailbox-get 'flags))))
 		    (gnus-info-set-marks
 		     info
 		     (nnimap-update-alist-soft
@@ -950,6 +951,8 @@
 		marks)
 	    ;; cache flags are pointless on the server
 	    (setq cmdmarks (delq 'cache cmdmarks))
+	    ;; recent marks can't be set
+	    (setq cmdmarks (delq 'recent cmdmarks))
 	    (when nnimap-importantize-dormant
 	      ;; flag dormant articles as ticked
 	      (if (memq 'dormant cmdmarks)
@@ -1293,6 +1296,7 @@
 		'((read . "SEEN")
 		  (tick . "FLAGGED")
 		  (draft . "DRAFT")
+		  (recent . "RECENT")
 		  (reply . "ANSWERED")))
 	 (cons (cdr pair)
 	       (format "KEYWORD gnus-%s" (symbol-name (cdr pair))))))
@@ -1311,6 +1315,7 @@
 		'((read . "\\Seen")
 		  (tick . "\\Flagged")
 		  (draft . "\\Draft")
+		  (recent . "\\Recent")
 		  (reply . "\\Answered")))
 	 (cons (cdr pair)
 	       (format "gnus-%s" (symbol-name (cdr pair))))))

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> I've been running with my "new" mark patch for a while, and altough it
> isn't perfect I've actually found it useful.  So maybe you'd like to
> test it.

Very nice!

Can it also set the `%' mark on the group in the group buffer?  (I
know it doesn't, but how difficult would it be to do that?)  Hm.
Probably it already works with nnimap-split-rule, but I use
server-side splitting (with sieve).

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Simon Josefsson <jas@extundo.com> writes:
> 
>> I've been running with my "new" mark patch for a while, and altough it
>> isn't perfect I've actually found it useful.  So maybe you'd like to
>> test it.
> 
> Very nice!

Try it for a week and tell me if you think it should be committed
(with the proper documentation of course) or not.

> Can it also set the `%' mark on the group in the group buffer?  (I
> know it doesn't, but how difficult would it be to do that?)  Hm.
> Probably it already works with nnimap-split-rule, but I use
> server-side splitting (with sieve).

The following does it.  It's not exactly the same behaviour as nnmail.
In nnmail the indicator indicates whether nnmail has splitted mail
during this session or not. Instead this indicates if the server has
mail you've never seen.  But fortunately the documentation is fuzzy
and I think we're still in agreement with this:

`m'
     `%' (`gnus-new-mail-mark') if there has arrived new mail to the
     group lately.


Index: nnimap.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/nnimap.el,v
retrieving revision 6.12
diff -u -u -w -u -w -r6.12 nnimap.el
--- nnimap.el	2001/07/27 01:29:36	6.12
+++ nnimap.el	2001/08/05 20:26:41
@@ -866,6 +866,10 @@
 	(or (member "\\NoSelect"
 		    (imap-mailbox-get 'list-flags group nnimap-server-buffer))
 	    (let ((info (nnimap-find-minmax-uid group 'examine)))
+	      (when (> (or (imap-mailbox-get 'recent group 
+					     nnimap-server-buffer) 0)
+		       0)
+		(push (list (cons group 0)) nnmail-split-history))
 	      (insert (format "\"%s\" %d %d y\n" group
 			      (or (nth 2 info) 0)
 			      (max 1 (or (nth 1 info) 1))))))))

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
>> Simon Josefsson <jas@extundo.com> writes:
>> 
>>> I've been running with my "new" mark patch for a while, and altough it
>>> isn't perfect I've actually found it useful.  So maybe you'd like to
>>> test it.
>> 
>> Very nice!
>
> Try it for a week and tell me if you think it should be committed
> (with the proper documentation of course) or not.

Maybe it's a day early.  I fell in love with that feature instantly.
I couldn't live without it.  (`That feature' being both the N mark in
the summary buffer and the % mark in the group buffer.)

Please commit the patch.

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Maybe it's a day early.  I fell in love with that feature instantly.
> I couldn't live without it.  (`That feature' being both the N mark in
> the summary buffer and the % mark in the group buffer.)
>
> Please commit the patch.

Ok, done.  Thanks for testing.

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
>> Please commit the patch.
>
> Ok, done.  Thanks for testing.

My working directory still differs from the repository:

Index: lisp/gnus.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus.el,v
retrieving revision 6.40
diff -u -r6.40 gnus.el
--- lisp/gnus.el	2001/08/11 22:21:43	6.40
+++ lisp/gnus.el	2001/08/12 16:57:51
@@ -1787,7 +1787,8 @@
     (bookmarks . bookmark) (dormant . dormant)
     (scored . score) (saved . save)
     (cached . cache) (downloadable . download)
-    (unsendable . unsend) (forwarded . forward)))
+    (unsendable . unsend) (forwarded . forward)
+    (recent . recent)))
 
 (defvar gnus-headers-retrieved-by nil)
 (defvar gnus-article-reply nil)

Did you forget something or did I do something wrong?

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> My working directory still differs from the repository:

Oops. Better now?

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
>> My working directory still differs from the repository:
>
> Oops. Better now?

Yep.

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> I've been running with my "new" mark patch for a while, and altough it
> isn't perfect I've actually found it useful.

That looks very nice for nnimap groups, but I wonder whether something
like this could be handled more generally by Gnus.

That is, Gnus would start keeping track of which articles the user had
requested before.

Let me explain.

The user enters a group with the articles 300-400 in it.  Gnus adds
a `(seen (300 . 400))' range to the group in .newsrc.eld.  The next
time the user enters the group with articles 300-450 in it, Gnus would
know that 401-450 were new and could be marked with
`gnus-recent-mark'.

What do you think?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> The user enters a group with the articles 300-400 in it.  Gnus adds
> a `(seen (300 . 400))' range to the group in .newsrc.eld.  The next
> time the user enters the group with articles 300-450 in it, Gnus would
> know that 401-450 were new and could be marked with
> `gnus-recent-mark'.
>
> What do you think?

I had a slightly different idea -- have the nnmail splitter add the
`recent' flags. The splitter knows what articles are newly added to
the group.  But it wouldn't work for nntp groups.

But yes, I like your idea.  I presume the `(seen (300 . 400))' would
be a group parameter?

(Only thing I don't like is that it increases the amount of state
stored in .newsrc.eld.  That's basicly why I had the nnmail splitter
idea.)

Re: `new' indicator for nnimap groups?

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> I had a slightly different idea -- have the nnmail splitter add the
> `recent' flags. The splitter knows what articles are newly added to
> the group.  But it wouldn't work for nntp groups.

Mm.  Or nnslashdot groups.  

> But yes, I like your idea.  I presume the `(seen (300 . 400))' would
> be a group parameter?

It would be in the marks list, I think.

> (Only thing I don't like is that it increases the amount of state
> stored in .newsrc.eld.  That's basicly why I had the nnmail splitter
> idea.)

Well, since this seems to be a concern many people has, perhaps doing
a general fork-out of these bits of data into other files would be a
good idea.  (It's been suggested.)  However, I don't really see
storing many bits of data in many files as much of an improvement.
Sure, when you hose one file, you don't lose the data in the other
files, but now you have many more hoseable files, so you can lose bits
of data at the same general rate, but less drastically.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Well, since this seems to be a concern many people has, perhaps doing
> a general fork-out of these bits of data into other files would be a
> good idea.  (It's been suggested.)  However, I don't really see
> storing many bits of data in many files as much of an improvement.
> Sure, when you hose one file, you don't lose the data in the other
> files, but now you have many more hoseable files, so you can lose bits
> of data at the same general rate, but less drastically.  :-)

If you store them bits together with the messages somehow, then you
can more easily carry around the messages plus the bits.  That's a
really great thing.

Imagine I want to burn all my nnml messages on a CD and read them at
home.  Then I could burn the bits file, too, and everything would be
as if I was still at work, except that maybe I'm using a different
NNTP server at home, and stuff.

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> If you store them bits together with the messages somehow, then you
> can more easily carry around the messages plus the bits.  That's a
> really great thing.

That's true.  Storing the knowledge about something with that
something is a good thing.  However, that means that you are the only
one that has access to that something, which is usually not generally
a good assumption to make.

With mail, however, that's usually how it works...

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: `new' indicator for nnimap groups?

[Paul Jarc]

Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> If you store them bits together with the messages somehow, then you
>> can more easily carry around the messages plus the bits.  That's a
>> really great thing.
> 
> That's true.  Storing the knowledge about something with that
> something is a good thing.  However, that means that you are the only
> one that has access to that something, which is usually not generally
> a good assumption to make.

When I did this for nnmaildir, I tried to make it so it would be easy
to manipulate the marks from, say, your shell, using ln, mv, rm, and
such.  So this information is fairly accessible to non-Gnusy things.

Storing the marks in the backend instead of .newsrc.eld wouldn't
really keep the information away from Gnus, either, since Gnus has a
way to ask the backend for it.


paul

Re: `new' indicator for nnimap groups?

[Lars Magne Ingebrigtsen]

prj@po.cwru.edu (Paul Jarc) writes:

> When I did this for nnmaildir, I tried to make it so it would be easy
> to manipulate the marks from, say, your shell, using ln, mv, rm, and
> such.  So this information is fairly accessible to non-Gnusy things.

Sure.  But I meant other people; not other programs.  Storing the bits
that says how you're reading a repository of information in the
repository means that somebody else can't do the same.

That's pretty academic for mail groups, but for all other groups, it's
important. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: `new' indicator for nnimap groups?

[Paul Jarc]

Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> Sure.  But I meant other people; not other programs.  Storing the bits
> that says how you're reading a repository of information in the
> repository means that somebody else can't do the same.

Ah, ok.  Well, I also made it so you can share a maildir with other
people, and the marks can be either shared or not.  You can even share
all 'reply marks but not 'tick marks, etc., if you like.  (I probably
ought to document that...)  Symlinks are my friends: everything can be
accessed through the usual private name, even if some of it is
actually shared.

> That's pretty academic for mail groups, but for all other groups, it's
> important. 

For other groups, I can't imagine how one would go about storing the
marks with the messages anyway.


paul

Re: `new' indicator for nnimap groups?

[Lars Magne Ingebrigtsen]

prj@po.cwru.edu (Paul Jarc) writes:

> Ah, ok.  Well, I also made it so you can share a maildir with other
> people, and the marks can be either shared or not.

Oh, cool.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: `new' indicator for nnimap groups?

[Paul Jarc]

I wrote:
> Well, I also made it so you can share a maildir with other people,
> and the marks can be either shared or not.

I should clarify this.  If two pepole are sharing marks, then it's
possible for them to step on each other's toes if they're accessing
the maildir at the same time.  Before entering a group, they'd need to
do M-g in case the other person changed any marks.  Also, they'd need
to exit the group before the other entered it - otherwise, the first
Gnus to exit the group might have its updates clobbered by the other
one.

I think this danger would disappear if -request-set-mark always
received 'add and 'del forms, and never 'set.  'set assumes that Gnus
knows which marks are already set, which isn't possible if someone
else might update the marks just after you look.  'add and 'del just
express the difference between the old and new marks, and it should be
safe to apply two sets of differences that don't know about each
other.  (nnmaildir doesn't mind if you set an already-set mark, or
unset a not-set mark.)


paul

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

prj@po.cwru.edu (Paul Jarc) writes:

> I think this danger would disappear if -request-set-mark always
> received 'add and 'del forms, and never 'set.  'set assumes that Gnus
> knows which marks are already set, which isn't possible if someone
> else might update the marks just after you look.  'add and 'del just
> express the difference between the old and new marks, and it should be
> safe to apply two sets of differences that don't know about each
> other.  (nnmaildir doesn't mind if you set an already-set mark, or
> unset a not-set mark.)

FWIW nnimap support shared flags, this is why `set' is never used by
Gnus (Gnus does extra work to calculate proper add/del actions instead
of simply using set).  Hm, except when moving an article between one
group and another.

Ok, moving articles use the `add' action now, and the documentation
for `set' is removed.

(Though there is a temporal ordering between two independent processes
that set marks that may cause problems.  When doing the update, it
does not check WHEN the USER invoked the mark change, the change
always take effect NOW.  So a Agent user marking everything as unread,
then disappears for two years, and comes back and syncs his flags will
flag everything as unread even though other users may have marked
things as read meanwhile.  Leaving a summary buffer open for days and
then quiting it would be a less radical example.  But I think the
behaviour is simple to understand so it shouldn't cause too much
problems.  The one that applies his changes last wins.)

Re: `new' indicator for nnimap groups?

[Paul Jarc]

Simon Josefsson <jas@extundo.com> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> I think this danger would disappear if -request-set-mark always
>> received 'add and 'del forms, and never 'set.
> 
> FWIW nnimap support shared flags, this is why `set' is never used by
> Gnus (Gnus does extra work to calculate proper add/del actions instead
> of simply using set).  Hm, except when moving an article between one
> group and another.

Well, that shouldn't be a problem.  If you and I are looking at the
same group, and I move an article into it, you aren't going to see
that article until you exit the group and rescan.  So when you exit,
your mark updates aren't going to affect the new article.  Right?


paul

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> That's pretty academic for mail groups, but for all other groups, it's
> important. 

Ah, now I understand.  Well, files akin to .newsrc.eld could be used
for nntp servers.  Except that now, the topic topology and stuff would
be stored in .newsrc.eld (or .gnus.eld or something) and the article
marks would be stored in some file named after the server.

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Sure.  But I meant other people; not other programs.  Storing the bits
> that says how you're reading a repository of information in the
> repository means that somebody else can't do the same.

Well, the location where bits are to be stored in could be separate
for each user.

Anyway, I think this could actually be useful.  If say, nnml, would be
self-contained, you could share a nnml directory with someone and also
share the flags with that someone.  Without sharing .newsrc.eld.  So
you can have a department wide nnml group which shares marks.

Of course, if you don't want to share the marks, you simply disable
the self-containedness on that group/server.

Re: `new' indicator for nnimap groups?

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> Anyway, I think this could actually be useful.  If say, nnml, would be
> self-contained, you could share a nnml directory with someone and also
> share the flags with that someone.  Without sharing .newsrc.eld.  So
> you can have a department wide nnml group which shares marks.

That would indeed be useful.  To take a completely hypothetical
example -- an IT department (of, say, an online stock broker) who
shares the task of responding to technical email.

Would be very handy.

> Of course, if you don't want to share the marks, you simply disable
> the self-containedness on that group/server.

Indeed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: `new' indicator for nnimap groups?

[Sudish Joseph]

Lars Magne Ingebrigtsen writes:
> prj@po.cwru.edu (Paul Jarc) writes:
>> When I did this for nnmaildir, I tried to make it so it would be easy
>> to manipulate the marks from, say, your shell, using ln, mv, rm, and
>> such.  So this information is fairly accessible to non-Gnusy things.

> Sure.  But I meant other people; not other programs.  Storing the bits
> that says how you're reading a repository of information in the
> repository means that somebody else can't do the same.

> That's pretty academic for mail groups, but for all other groups, it's
> important. 

[ Apologies for the long-delayed followups, but these be interesting
topics. ]

Having Gnus' metadata (i.e., .newsrc.eld) be network-transparent would
be very cool.  IMAP allows server-side state, so nnimap is in good
shape here.  However, stuff like nntp would benefit from similar
network-accessible state storage.  There's even an existing protocol
that could be used: ACAP.

Here's the Project Cyrus web page on ACAP: http://asg.web.cmu.edu/acap/

Some vendors have already integrated ACAP or its ancestor, IMSP, into
IMAP clients.  For instance, here's a paper on integration in Mulberry
(an IMAP client): ftp://ftp.cyrusoft.com/pub/Mulberry/docs/imsp_guide.pdf

Another application, detailed in that last paper, would be to
transform Gnus' splitting information into SIEVE format and store in
in an ACAP server.

-- 
Sudish Joseph

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

Sudish Joseph <sudish@mindspring.com> writes:

> There's even an existing protocol that could be used: ACAP.
>
> Here's the Project Cyrus web page on ACAP: http://asg.web.cmu.edu/acap/

>From what I've (not) seen, ACAP hasn't moved much in 2 years.

> Some vendors have already integrated ACAP or its ancestor, IMSP, into
> IMAP clients.  For instance, here's a paper on integration in Mulberry
> (an IMAP client): ftp://ftp.cyrusoft.com/pub/Mulberry/docs/imsp_guide.pdf

Yeah, even IMSP is more common than ACAP.

> Another application, detailed in that last paper, would be to
> transform Gnus' splitting information into SIEVE format and store in
> in an ACAP server.

I think ACAP is the wrong solution for Sieve scripts.

To properly use Sieve over the network, the server has to be able to
parse the sieve script to reject invalid scripts.  Since ACAP is
generic, someone will store procmail scripts there as well.  And so on
until it parses Visual Basic and plays Tetris.  Having the ACAP server
parse various weird languages isn't good for performance or security.

I like Tim Martin's Managesieve protocol much better.  It is
implemented in Cyrus IMAPD and there is a Emacs interface to it at
<URL:http://josefsson.org/sieve/>.  And thanks to NAGY Andras it has a
nice Gnus interface as well. I've been using this for my splitting
pleasures since April or so.

It's not possible to transform Gnus' splitting rules into Sieve
though, since Sieve isn't turing complete (and far from providing the
functionality needed to implement most things we would need).

Re: `new' indicator for nnimap groups?

[Amos Gouaux]

>>>>> On Mon, 27 Aug 2001 19:46:41 +0200,
>>>>> Simon Josefsson <jas@extundo.com> (sj) writes:

sj> To properly use Sieve over the network, the server has to be able to
sj> parse the sieve script to reject invalid scripts.  Since ACAP is
sj> generic, someone will store procmail scripts there as well.  And so on
sj> until it parses Visual Basic and plays Tetris.

You forgot elisp!  ;-)

-- 
Amos

Re: `new' indicator for nnimap groups?

[Amos Gouaux]

>>>>> On Mon, 27 Aug 2001 19:46:41 +0200,
>>>>> Simon Josefsson <jas@extundo.com> (sj) writes:

>> Here's the Project Cyrus web page on ACAP: http://asg.web.cmu.edu/acap/

sj> From what I've (not) seen, ACAP hasn't moved much in 2 years.

It's a shame too.  I hate to see LDAP bloated for that kind of
thing.  I'm able to stretch my mind just enough to see LDAP as a
naming service for UNIX, but as a preference database--that just
seems way untidy.

I've been tempted to play with the thing on my.gnus.org for storing
stuff in an IMAP folder or something like that, but so little time
to play right now.

-- 
Amos

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> That's true.  Storing the knowledge about something with that
> something is a good thing.  However, that means that you are the only
> one that has access to that something, which is usually not generally
> a good assumption to make.

Hm?  Do you share .newsrc.eld with your girlfriend, or something?

kai
-- 
~/.signature: No such file or directory

Re: `new' indicator for nnimap groups?

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Hm?  Do you share .newsrc.eld with your girlfriend, or something?

No.  That's my point.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: `new' indicator for nnimap groups?

[Joe Casadonte]

On Fri, 17 Aug 2001, Lars Magne Ingebrigtsen wrote:

> Well, since this seems to be a concern many people has, perhaps
> doing a general fork-out of these bits of data into other files
> would be a good idea.  (It's been suggested.)  However, I don't
> really see storing many bits of data in many files as much of an
> improvement.  Sure, when you hose one file, you don't lose the data
> in the other files, but now you have many more hoseable files, so
> you can lose bits of data at the same general rate, but less
> drastically.  :-)

I'm already mailing my .newsrc.eld between home & work, I'd hate to
have to mail 20 files instead.  Just one man's opinion....

--
Regards,

joe
Joe Casadonte
jcasadonte@northbound-train.com

------------------------------------------------------------------------------
         Llama Fresh Farms => http://www.northbound-train.com
   Gay Media Resource List => http://www.northbound-train.com/gaymedia.html
            Perl for Win32 => http://www.northbound-train.com/perlwin32.html
               Emacs Stuff => http://www.northbound-train.com/emacs.html
          Music CD Trading => http://www.northbound-train.com/cdr.html
------------------------------------------------------------------------------
                       Live Free, that's the message!
------------------------------------------------------------------------------

Re: `new' indicator for nnimap groups?

[Paul Jarc]

"Joe Casadonte" <jcasadonte@northbound-train.com> wrote:
> I'm already mailing my .newsrc.eld between home & work, I'd hate to
> have to mail 20 files instead.  Just one man's opinion....

Maybe rsync or something would be more convenient?  Maybe easier to
automate, too, in which case 20 is as easy as 1.


paul

Re: `new' indicator for nnimap groups?

[Joe Casadonte]

On Fri, 17 Aug 2001, Paul Jarc wrote:

> "Joe Casadonte" <jcasadonte@northbound-train.com> wrote:
>> I'm already mailing my .newsrc.eld between home & work, I'd hate to
>> have to mail 20 files instead.  Just one man's opinion....
>
> Maybe rsync or something would be more convenient?  Maybe easier to
> automate, too, in which case 20 is as easy as 1.

Thanks for the suggestion.  I'd have to sync via a third-party,
though (like my mail server perhaps), as neither system is accessible
directly.

--
Regards,

joe
Joe Casadonte
jcasadonte@northbound-train.com

------------------------------------------------------------------------------
         Llama Fresh Farms => http://www.northbound-train.com
   Gay Media Resource List => http://www.northbound-train.com/gaymedia.html
            Perl for Win32 => http://www.northbound-train.com/perlwin32.html
               Emacs Stuff => http://www.northbound-train.com/emacs.html
          Music CD Trading => http://www.northbound-train.com/cdr.html
------------------------------------------------------------------------------
                       Live Free, that's the message!
------------------------------------------------------------------------------

Re: `new' indicator for nnimap groups?

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> (Only thing I don't like is that it increases the amount of state
>> stored in .newsrc.eld.  That's basicly why I had the nnmail splitter
>> idea.)
>
> Well, since this seems to be a concern many people has, perhaps doing
> a general fork-out of these bits of data into other files would be a
> good idea.  (It's been suggested.)  However, I don't really see
> storing many bits of data in many files as much of an improvement.
> Sure, when you hose one file, you don't lose the data in the other
> files, but now you have many more hoseable files, so you can lose bits
> of data at the same general rate, but less drastically.  :-)

Maybe it should be configurable<tm>.  If the backend can't store flags
or the user doesn't want it, Gnus uses .newsrc.eld.

Removing cruft from .newsrc.eld is quite difficult though.  I think we
could simply extend the backends to be self-contained and let the junk
stay in .newsrc.eld.  Similar to what nnimap (and I suppose nnmaildir)
does with marks today -- the info is still in .newsrc.eld but the
backend fixes it before it's used.

Re: `new' indicator for nnimap groups?

[Sudish Joseph]

Lars Magne Ingebrigtsen writes:
> Well, since this seems to be a concern many people has, perhaps doing
> a general fork-out of these bits of data into other files would be a
> good idea.  (It's been suggested.)  However, I don't really see
> storing many bits of data in many files as much of an improvement.
> Sure, when you hose one file, you don't lose the data in the other
> files, but now you have many more hoseable files, so you can lose bits
> of data at the same general rate, but less drastically.  :-)

Sure, but data loss isn't the only reason to split data out: large
data structures (the killed group list, for instance) that change
infrequently can be usefully split out to separate files from things
like the mark list.  This saves the cost in marshalling and writing
out these structures every time the user exits (or in my case,
suspends Gnus).

-- 
Sudish Joseph

Re: `new' indicator for nnimap groups?

[Joe Casadonte]

On Fri, 17 Aug 2001, Simon Josefsson wrote:

> I had a slightly different idea -- have the nnmail splitter add the
> `recent' flags. The splitter knows what articles are newly added to
> the group.  But it wouldn't work for nntp groups.

Nor would it for those of us that use something other than the nnmail
splitter, like procmail....

--
Regards,

joe
Joe Casadonte
jcasadonte@northbound-train.com

------------------------------------------------------------------------------
         Llama Fresh Farms => http://www.northbound-train.com
   Gay Media Resource List => http://www.northbound-train.com/gaymedia.html
            Perl for Win32 => http://www.northbound-train.com/perlwin32.html
               Emacs Stuff => http://www.northbound-train.com/emacs.html
          Music CD Trading => http://www.northbound-train.com/cdr.html
------------------------------------------------------------------------------
                       Live Free, that's the message!
------------------------------------------------------------------------------

Re: `new' indicator for nnimap groups?

[Kai Großjohann]

"Joe Casadonte" <jcasadonte@northbound-train.com> writes:

> On Fri, 17 Aug 2001, Simon Josefsson wrote:
>
>> I had a slightly different idea -- have the nnmail splitter add the
>> `recent' flags. The splitter knows what articles are newly added to
>> the group.  But it wouldn't work for nntp groups.
>
> Nor would it for those of us that use something other than the nnmail
> splitter, like procmail....

Even with procmail, proper use is via a `directory' mail source, so
the nnmail splitter gets involved.

nnimap users don't use the nnmail splitter.

kai
-- 
~/.signature: No such file or directory