[notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages
Michiel Buddingh'
michiel at michielbuddingh.net
Thu Nov 26 13:12:02 PST 2009
Carl Worth <cworth at cworth.org> wrote:
> > + " The other value is 'storage_type', which can currently be set to\n"
> > + " 'maildir' or 'none'.\n";
>
> This part of the patch I don't like. I've got a mail collection spanning
> over a decade, and it's seen a lot of strange things. Most of my mail is
> in maildir format, but not quite all of it. And I actually like the
> ability to just shove random new messages into the mail store manually
> without having to create a maildir name for it.
>
> So I don't think a global configuration makes sense here. Meanwhile,
> it's really easy to detect the presence of a maildir. Whenever we see
> child directories of "cur", "new", and "tmp" then we should turn on the
> processing of maildir flags for when processing mail in "cur" and "new".
I considered that approach; ideally, we could test for the presence of
all three of cur, tmp and new--but this is rather messy to do in the
current treewalk structure. Taking any one of them as proof positive of
a Maildir might lead to unpleasant surprises--it's not all that incon-
ceivable for someone to name a mail folder 'tmp'.
There's another matter; Some mail stores will place (large) index files
in folder roots, i.e. one level above cur/, tmp/ and new/. Looking
at the ones dovecot (an IMAP server) uses, I can make out a from header,
a subject header, and a message-id, as plaintext in the first 100k or
so. It's not all that inconceivable that notmuch might register it as
a 'real' email, with unpleasant consequences for the index.
I've seen some patches fly by that add support for multiple mail
stores. Turning on Maildir support on a per-directory basis might
resolve that problem while still supporting heterogenous mail archives
to some degree. I am not convinced we can do the right thing
automatically without causing some grief to a subset of users.
> > @@ -257,7 +262,7 @@ notmuch_config_open (void *ctx,
> > talloc_free (email);
> > }
> > }
> > -
> > +
> > /* When we create a new configuration file here, we add some
> > * comments to help the user understand what can be done. */
> > if (is_new) {
>
> [nit] Trailing whitespace inserted there as well.
> Hmm... I was going to say that git ships with a pre-commit hook you can
> turn on that checks for trailing whitespace and aborts the commit if
> it's present. But it looks like the currently shipping pre-commit.sample
> hook doesn't do this anymore.
Haven't tested it, but it seems you can put
[core]
whitespace = trailing-space,space-before-tab
into your ~/.gitconfig now. I've also set emacs to mark trailing
whitespace with big red markers.
> OK, now we're into the meat of things. Clearly, you're directly
> supporting the documented flags of maildir. But we need to do a few
> things differently here. Most importantly, notmuch is already using an
> "unread" tag, so maildir's S flag should map that *that* rather than
> adding new "unseen" and "seen" flags. So messages with the S flag would
> not get the "unread" tag and messages without S would get the "unread"
> tag.
When writing the patch, I assumed there might be a minor (but important)
distinction between marking a mail 'seen' (i.e. the MUA storing the fact
that the file has been visited) and 'read' (i.e. the user marking the
contents of a mail as being read and understood). As I found out later,
notmuch's interpretation of 'read' and 'unread' is the former, so there
is no distinction.
> The "flagged" and "replied" tags seem reasonable enough. But for
> "trashed" and "passed" I think I'd rather see the tag names as "deleted"
> and "forwarded". (Since I can imagine adding commands to notmuch for
> "delete" and "forward" but not for "trash" nor "pass").
Fair enough.
> Oh, and setting the "inbox" tag correctly here based on the maildir tags
> is the final and most important thing. It looks like that's missing from
> the above. So, a missing "S" flag should map to adding both the "inbox"
> and "unread" tags.
Makes sense, will do.
> > + if (state->storage_type == MAILDIR) {
> > + char * leaf = basename(next);
>
> You could save the basename call by examining the leaf name when it is
> available as a standalone string up in the caller.
Which would require testing with S_ISDIR twice, which is uglier, but
essentially free, so I'll grant it's the better thing to do.
> So this patch is close, but needs a few fixes.
I'll be happy to implement them, although I'd like for others to chime
in on the configure-as-Maildir vs. autodetect-Maildir issue. And thanks
for your patience in working through my patch.
--
Michiel Buddingh'
More information about the notmuch
mailing list