Re: [PATCH 1/3] new: Do not defer maildir flag synchronization during the first run

diff --git a/d9/18ceac74f3f824b3de7af7de119c402a455604 b/d9/18ceac74f3f824b3de7af7de119c402a455604
new file mode 100644 (file)
index 0000000..2758e0f
--- /dev/null
+++ b/d9/18ceac74f3f824b3de7af7de119c402a455604
@@ -0,0 +1,105 @@
+Return-Path: <cworth@cworth.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 8DEDF431FD0\r
+       for <notmuch@notmuchmail.org>; Wed, 26 Jan 2011 01:15:23 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.99\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5\r
+       tests=[ALL_TRUSTED=-1, T_MIME_NO_TEXT=0.01] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id MfRH1clNTlEl; Wed, 26 Jan 2011 01:15:22 -0800 (PST)\r
+Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id F0502431FB5;\r
+       Wed, 26 Jan 2011 01:15:21 -0800 (PST)\r
+Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
+       id 349372540E0; Wed, 26 Jan 2011 19:15:21 +1000 (EST)\r
+From: Carl Worth <cworth@cworth.org>\r
+To: Austin Clements <amdragon@mit.edu>, Michal Sojka <sojkam1@fel.cvut.cz>\r
+Subject: Re: [PATCH 1/3] new: Do not defer maildir flag synchronization during\r
+       the first run\r
+In-Reply-To: <AANLkTinsC+89yx7jGUaB8PLiftLjyTr7gosUDgAC_g0S@mail.gmail.com>\r
+References: <1295603977-14326-1-git-send-email-sojkam1@fel.cvut.cz>\r
+       <1295603977-14326-3-git-send-email-sojkam1@fel.cvut.cz>\r
+       <AANLkTinsC+89yx7jGUaB8PLiftLjyTr7gosUDgAC_g0S@mail.gmail.com>\r
+User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.2.1\r
+       (i486-pc-linux-gnu)\r
+Date: Wed, 26 Jan 2011 19:15:21 +1000\r
+Message-ID: <87pqrk10wm.fsf@yoom.home.cworth.org>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Wed, 26 Jan 2011 09:15:23 -0000\r
+\r
+--=-=-=\r
+\r
+On Tue, 25 Jan 2011 17:42:30 -0500, Austin Clements <amdragon@mit.edu> wrote:\r
+> Wouldn't this be simpler and more general?\r
+...\r
+>         case NOTMUCH_STATUS_SUCCESS:\r
+..\r
+>             if (state->synchronize_flags == TRUE)\r
+> -               _filename_list_add (state->message_ids_to_sync,\r
+> -                                   notmuch_message_get_message_id (message));\r
+> +               notmuch_message_maildir_flags_to_tags (message);\r
+\r
+Yes, that is much simpler and should work equally well as the original\r
+patch.\r
+\r
+But there's perhaps a problem with both of these patches. Besides\r
+rename, (which obviously can't happen with a new message), we also need\r
+to take care when a message is added with multiple filenames (and with\r
+different flags on the files).\r
+\r
+We've got a plan for adding flags-to-tags mappings which only apply if\r
+every file for the message has the corresponding flag. For example, this\r
+is the semantic we want for the 'D' flag mapping to the "deleted" tag.\r
+\r
+So we'll want to make sure these cases do the right thing. Consider two\r
+new files with the same Message-Id both appearing in a run of "notmuch\r
+new", one with the D flag and one without.\r
+\r
+If the file with the D flag is seen first, and the maildir_flags_to_tags\r
+processing happens without being deferred, then the "deleted" tag will\r
+be applied to the message. This is different than would happen if both\r
+messages were seen, but I think it's just fine. It's still in a state\r
+that's consistent, nothing bad would happen if you interrupted this and\r
+then acted on the "deleted" tag, and if you restarted "notmuch new" and\r
+the second message were seen, then the tag would be correctly removed.\r
+\r
+So, I think I've convinced myself that the change is actually OK. But\r
+then I'm also wondering if perhaps we could do the processing undeferred\r
+in all cases?\r
+\r
+I haven't thought that through, but I'd be glad to hear your ideas.\r
+\r
+-Carl\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.10 (GNU/Linux)\r
+\r
+iD8DBQFNP+Yp6JDdNq8qSWgRAub7AJ9hO3Yi5LZdB+M6YVIG/FnUF0Vt/QCeLMar\r
+qknMTSgX/oBrZWRT2lXgZP8=\r
+=Yxg1\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r