[notmuch] Some thoughts about notmuch sync with other agents

[Sebastian Spaeth]

REPOSTING, as the previous reply went to Gmane

> One may
> or may not like IMAP for good reasons, the fact is that it is here and
> has allowed users to read mails from various places and terminals,
> keeping important information synced. So I think that notmuch will have
> to live with that, and provide what is required to integrate smoothly
> into this environment.

agreed

> First of all, processing mail with MUA involves some simple logic that
> is shared by most MUA. This is about receiving *new* mails, *reading*
> mail, *replying* to mail and so on... IMHO, this really belongs to the
> mail processing logic and not to the user logic. Hence my first
> request :
>   1: Don't use user tags space to store MUA flags.

I don't really see what you gain by this proposal. I don't necessarily
think it's bad either, but there is no advantage IMHO.

What you propose is basically that those tags are not directly seen by
the user and not modifiable by the user. What's the advantage over
having a small set of "reserved tag keywords"? Your notmuch-capable
editor could still chose to not display "unread" and "deleted" tags but
simply hide deleted mails and show unread mails in bold or so. I simply
don't think it's important how tags are stored and the current scheme is
dead simple which makes it pretty nice.
 
>      That means no more "seen", "unread", "replied" as tags. These are
>      MUA processing *flags*, that must belong to an established set.
>      Tags, on the other hand, are user-land information. So no more
>      [seen, replied, grandma, important] tag sets :)

See above, the mail editor might chose to hide thos MUA processing
flags, but I don't think it is important whether they are hidden by the
user or now. 

Other than that, I agree that "notmuch new" should set a "new" and/or
"modified"tag if it detects a new mail (or a modified one), rather than
the current set of fixed tags that aren't too helpful for 3rd party
scripts.

Sebastian 
-------------- next part --------------
Date: Mon, 01 Feb 2010 15:54:57 +0100
Message-ID: <871vh557lq.fsf at SSpaeth.de>