Re: Gnus5, procmail, and reading mail lists.

[steve@miranova.com (Steven L. Baur)]

>>>>> "Joe" == Joe Hildebrand <hildjj@fuentez.com> writes:

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:
    Steven> If you are going to use Gnus expiration, it is important
    Steven> to also set: (setq nnmail-keep-last-article t)

    Joe> I thought this was only if procmail was delivering directly
    Joe> to the nnm[lh] directory.

You're correct.

    Steven> If you are going to generate NOV databases out of
    Steven> procmail, you will have to deal with the same locking
    Steven> issues you face with the spool files, with the added
    Steven> nicety that while the NOV database is being updated Gnus
    Steven> must be locked out too.  I don't think anybody is doing it
    Steven> this way.

    Joe> Anymore.  Some people may still be using add-active-nov.

When we had a similar discussion last month, something about this was
mentioned, but it went over my head.  I just reread the thread, and
saw again the comments about a procmail NOV hack, which I assume
add-active-nov is referring to.  I don't see a reference to it in
either the Gnus, XEmacs lisp source, nor procmail 3.10 source (or
dejanews for that matter).

    Steven> I had previously been using the pattern:
    Steven> ^TOding(-request)?  This doesn't work 100% mainly due to
    Steven> messages being Cc:'ed to you and the mailing list.

    Joe> procmailrc(5) says:
...
    Joe> which should catch CCs.

Exactly.  You end up with two messages with identical message-ids
going into the same nnml folder, one of which is now in a Gnus black
hole, and cannot be referenced reasonably, or two identical messages
going into the hyperarchive.

-- 
steve@miranova.com baur