From: Carl Worth <cworth@cworth.org>
To: Sebastian Spaeth <Sebastian@SSpaeth.de>, notmuch@notmuchmail.org
Subject: Re: [notmuch] [PATCH] notmuch-new: Respect maildir flags when
	importing a new message
In-Reply-To: <1267450136-31749-1-git-send-email-Sebastian@SSpaeth.de>
References: <20100216022128.GH22402@flamingspork.com>
	<1267450136-31749-1-git-send-email-Sebastian@SSpaeth.de>
Date: Wed, 07 Apr 2010 14:16:34 -0700
Message-ID: <878w8zq7yl.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Mon,  1 Mar 2010 14:28:56 +0100, Sebastian Spaeth <Sebastian@SSpaeth.de>=
 wrote:
> When importing a new mail do check for maildir tags and assign
> corresponding notmuch tags.

I think this is a useful thing to support, as obviously new users have
*some* state that's interesting to import (which messages have been
"seen" for example), and simply importing their entire email archive
with both the "inbox" and "unread" tags is not helpful. So I'd like to
figure out how to support this.

> Do note that this will only add tags when importing a really new
> message, and will not do anything when detecting a file rename
> (although someone should really make it honor file renames as
> well). Deleteing an existing message in another IMAP client will
> therefore not trigger tagging (as it counts as a file rename).

But I think we really need to fix that if we're going to claim that
notmuch "supports maildir flags" in any sense.

It's a fairly tricky issue though since we can have multiple files that
have the same message ID, but then have different maildir flags. And
it's the matter of arbitrary ordering which one of these files appears
as "new" and which one appears as a "rename".

It's not obvious to me what we can do here unless we make some
assumptions, (such as "mails always start without the seen flag, and
once it appears it can't be removed" or so). But I'd love some input
From=20someone who's thought harder about this than I have.

=2DCarl

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFLvPYy6JDdNq8qSWgRAn2VAJ43hlWfzlgN+hIlLopRVi0Bv3V2WgCglfLg
A5mGsN8HwOs/I3fE9pgs8dk=
=muZF
-----END PGP SIGNATURE-----
--=-=-=--