On Sun, 22 Nov 2009 00:25:43 +0100, Michiel Buddingh' <michiel at
michielbuddingh.net> wrote:
> (hi, new here, just subscribed today. Wanted to reply to Carl's
> earlier message I read in the archives, but since I don't have that,
> I'm replying to Bart's reply to that message)
Hi Michel, welcome to Notmuch!
> Any attempt to match tags up to directories will eventually have
> to deal with with the fact that tags can't be neatly mapped onto
> them. If I remove a directory-tag from a message, does this
> mean the message is removed from that directory? What if a
> message has two directory-tags, does it mean it's present in both
> directories?
Right. We definitely don't want a strong mapping here. I think one
answer could be that the initial import is different and can take the
directory names as a "hint" for initializing tag values. After that,
they are just tags in the database and the user can do whatever they
want.
This would mean that the user will need some other way to apply tags to
future messages that might be delivered to those same directories. And
we've got search-based tagging for that, (as well as manual tagging for
the case where a user was manually filing messages into folders before).
And while developing these search-based tags the user can use a
different tag name. Say there was a directory named "foo", then the user
might experiment with a search-based tag named "foo-search" and explore
the results of things like:
notmuch search tag:foo and not tag:foo-search
notmuch search tag:foo-search and not tag:foo
So even if in the end the user comes up with something that could
replace the original tag, it's probably still beneficial to have it
there when starting out.
> At the same time, this kind of interoperability would be highly
> desirable to those of us who access their mail using other
> clients (webmail, mobile phones, etc.) that expect hierarchical
> ordering.
That kind of thing is going to be "harder".
So far we're trying to stick with the principle that notmuch itself
doesn't mess with the data store. But then, we also want notmuch to be
very scriptable, so someone might write a tool that uses notmuch search
to export a set of hierarchical maildirs based on the tag names. (These
could even just be populated with symlinks like mairix does.) So
something like that could be really useful for integrating.
I'm very much of the opinion that the user shouldn't care at all about
the storage of the actual mail files that notmuch indexes.
> In the mean time, I've made a smaller, hopefully more harmless
> patch to let 'notmuch new' mark messages stored in a Maildir 'cur'
> folder as 'read' rather than 'unread'.
Can others who have more experience weigh in here? Will this do the
right thing for you? Do mail clients wait to move things into "cur"
after the user has actually read them, or is that just a place where
they are moved when the MUA _receives_ them?
-Carl
