Re: (provide 'nnmaildir)

[prj@po.cwru.edu (Paul Jarc)]

<URL:http://multivac.cwru.edu/prj/nnmaildir.el>
internal: major rewrite for performance; .nnmaildir-max replaced
          with .nnmaildir, storing NOV lines & other info
internal: old tmp/ files are deleted in -open-server instead of
          -close-server (which has evaporated); tmp/ files with
          multiple hard links are also deleted
feature: -request-replace-article
feature: -groups is now just a list of maildirs; group names are
         stored in the maildirs
feature: -add-lines controls whether Lines: is added when missing
bugfix: -retrieve-headers never actually handled numeric fetch-old
bugfix: -request-{rename,delete}-group no longer require user help
bugfix: -request-expire-articles returns a correct article list

This version uses more memory and is somewhat slower in starting up
and assimilating new messages, but it's much faster in generating
Summary buffers and requesting articles.

An nnmaildir select method looks like this:
'(nnmaildir "whatever" (nnmaildir-groups ("/path/to/maildir"
                                          "/path/to/another")))
Or, for just a single group:
'(nnmaildir "whatever" (nnmaildir-groups "/path/to/maildir"))
If you don't want Lines: added to requested articles when it's missing:
'(nnmaildir "whatever" (nnmaildir-add-lines nil) (nnmaildir-groups ...))

Another somewhat painful migration from previous versions:
- start Gnus; kill all nnmaildir groups; exit Gnus; exit Emacs
- in each maildir, run:
  $ rm .nnmaildir-max
  $ cd cur
  $ bash -c 'for i in *;do mv "$i" ../new/"${i%%:*}";done'

(This same process can be used anytime to reassign article numbers
starting from 1, if they start to get too sparse for you.)  If you
don't want to lose your marks, you'll have to create the .nnmaildir
files by hand. :/ It'd probably be easier to save a copy of each
Summary buffer and re-mark the articles after starting up the new
version.

To implement -request-accept-article, I need to write the current time
into a string as a plain time_t (e.g., "968039378").  Will this
necessarily involve tedious string operations to do the arithmetic to
combine the two elements of (current-time), or has this already been
done somewhere?

I'd like to make nnmaildir interoperable with other maildir user
agents (not that *I* ever user any others, but...), so that other
maildir agents could be used on the same maildir as nnmaildir (between
Gnus sessions; probably not simultaneously).  This requires nnmaildir
storing some marks: read, expirable, replied, and any other single
mark.  I'd have to tell Gnus about marks it doesn't know about when
starting up (which is possible with -request-update-info), and I'd
also have to grab notification whenever any of those marks are
set/unset (only partially doable, with -request-update-mark).  The
backend interface would have to change somewhat to accomodate this
goal - but is it worthwhile anyway?


paul