--- /dev/null
+Return-Path: <jani@nikula.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 21CC7431FBC\r
+ for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 01:33:46 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 cnUfVm1sY0SL for <notmuch@notmuchmail.org>;\r
+ Sat, 25 Jan 2014 01:33:10 -0800 (PST)\r
+Received: from mail-ea0-f177.google.com (mail-ea0-f177.google.com\r
+ [209.85.215.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id CBDF2431FB6\r
+ for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 01:33:09 -0800 (PST)\r
+Received: by mail-ea0-f177.google.com with SMTP id n15so1400491ead.36\r
+ for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 01:33:07 -0800 (PST)\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+ d=1e100.net; s=20130820;\r
+ h=x-gm-message-state:from:to:subject:in-reply-to:references\r
+ :user-agent:date:message-id:mime-version:content-type;\r
+ bh=Np2l6yNoM8oQEqs4pplOyelw5Tjd2QXf/8RAqusM2qc=;\r
+ b=QvyoQO4JBZqa1jgQjufs9T87r5to6MTwO5WWVfMHf0X4iGuTKXdaO4foNb94CsVs86\r
+ tNjX7V7rgm6lgNFcR5ENsIgz5eMZmGfqhB8mWcV7lHeR+n0WGxp4URBR/+obld7OowN8\r
+ l1MQeoGqNkWCgDo1gMztCmOXO/Wl+oMFQ1Kl6R89IR3cTf4G5X4Ho9suo5h8/P4X/MPE\r
+ /R07FQ1scSLFLV0HjpXuTpnYHPlWy5CLbVgEoaI2drdkIDj710kyUtYSRLRqzfylJZ6E\r
+ iu/Hnl2rlIpO/8jYIUD7EetpM/+9c3i6H+UgfgyT1rxsCCEyTSK/fbKXPUsEzOkaPLs+\r
+ QvzA==\r
+X-Gm-Message-State:\r
+ ALoCoQlHqX1YylKnv2AXSb1Jrpi7L6Q2Huwo1cCdJnfGxno37EdHa04oag6TQaDv8XrrQcn10rH0\r
+X-Received: by 10.15.41.7 with SMTP id r7mr389487eev.98.1390642387205;\r
+ Sat, 25 Jan 2014 01:33:07 -0800 (PST)\r
+Received: from localhost (dsl-hkibrasgw2-58c36f-91.dhcp.inet.fi.\r
+ [88.195.111.91])\r
+ by mx.google.com with ESMTPSA id 4sm13810215eed.14.2014.01.25.01.33.05\r
+ for <multiple recipients>\r
+ (version=TLSv1.2 cipher=RC4-SHA bits=128/128);\r
+ Sat, 25 Jan 2014 01:33:06 -0800 (PST)\r
+From: Jani Nikula <jani@nikula.org>\r
+To: Austin Clements <aclements@csail.mit.edu>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH 0/5] lib: make folder: prefix literal\r
+In-Reply-To: <87y525m649.fsf@awakening.csail.mit.edu>\r
+References: <cover.1389304779.git.jani@nikula.org>\r
+ <87y525m649.fsf@awakening.csail.mit.edu>\r
+User-Agent: Notmuch/0.17+44~ge3b4cd9 (http://notmuchmail.org) Emacs/24.3.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Sat, 25 Jan 2014 11:33:04 +0200\r
+Message-ID: <87r47wfltb.fsf@nikula.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\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: Sat, 25 Jan 2014 09:33:46 -0000\r
+\r
+On Fri, 24 Jan 2014, Austin Clements <aclements@csail.mit.edu> wrote:\r
+> On Thu, 09 Jan 2014, Jani Nikula <jani@nikula.org> wrote:\r
+>> Hi all, this series makes the folder: search prefix literal, or switches\r
+>> it from a probabilistic prefix to a boolean prefix. With this, you have\r
+>> to give the path from the maildir root to the folder you want in full,\r
+>> including the maildir cur/new component, if any. Examples:\r
+>\r
+> I strongly disagree with requiring the cur/new component. The cur/new\r
+> directory is an internal implementation detail of Maildir (and a rather\r
+> broken one at that) and no more a part of the "folder" of a piece of\r
+> mail than its final file name component. It's also the less obvious\r
+> user interface; if we require the cur/new component, we *will* get\r
+> people asking why their folder searches aren't working, but if we strip\r
+> the cur/new component, nobody will be surprised.\r
+>\r
+> I think the question is not whether we should strip cur/new, but when.\r
+> We've already defined a "_filename_is_in_maildir" test in\r
+> lib/message.cc, which we depend on for flag sync. It's simple, but I\r
+> think this would be the right thing to use for consistency.\r
+\r
+I'd like to discuss some of the reasons I chose to include the cur/new\r
+components. Admittedly, none of them are very strong on their own, but\r
+all of them together tilted my opinion towards requiring them.\r
+\r
+The way I see it, notmuch supports maildir, but does not require it. In\r
+many ways the messages are just files somewhere in the directory\r
+hierarchy. There are only a few cases where it matters that there are\r
+cur/new/tmp directories within a directory.\r
+\r
+If you strip cur and new, it becomes impossible to distinguish between\r
+files in foo, foo/cur, and foo/new - and one of the reasons for changing\r
+folder: in the first place is to be able to better distinguish between\r
+folders.\r
+\r
+Apparently mutt presents the difference between messages in new and cur\r
+to its users (so I've been told; I've never really used mutt), and our\r
+integration with mutt lacks that distinction. We could fix that by\r
+requiring the cur/new components in folder: searches.\r
+\r
+Speaking of consistency, compare _filename_is_in_maildir() with\r
+_entries_resemble_maildir() in notmuch-new.c. What should the indexed\r
+folder: prefix be if there is not all of cur, new, and tmp? We will\r
+actually index files in tmp if cur or new is not present! What if the\r
+missing sibling directories are added (or existing ones removed) later?\r
+Where's the consistency compared to new.ignore config, which also\r
+matches the cur/new components if so desired? Or consistency with\r
+notmuch search --output=files?\r
+\r
+My conclusion was that requiring *all* filesystem folder components\r
+as-is is consistent, most versatile, agnostic to Maildir or Maildir++\r
+implementation details wrt directory naming or hierarchy, without\r
+difficult corner cases, simplest to implement, and unsurprising (once\r
+you understand the cur/new distinction).\r
+\r
+For *me* this is the more obvious user interface. And hey, I'm a user\r
+too.\r
+\r
+Perhaps we need to have two prefixes, one of which is the literal\r
+filesystem folder and another which hides the implementation details,\r
+like I mentioned in my mail to Peter [1]. But consider this: my proposed\r
+implementation does cover *all* use cases.\r
+\r
+\r
+BR,\r
+Jani.\r
+\r
+\r
+[1] id:8761ppurfz.fsf@nikula.org\r
projects / notmuch-archives.git / commitdiff