--- /dev/null
+Return-Path: <m.walters@qmul.ac.uk>\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 3D2CE431FB6\r
+ for <notmuch@notmuchmail.org>; Tue, 6 May 2014 00:44:29 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.502\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.502 tagged_above=-999 required=5\r
+ tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
+ NML_ADSP_CUSTOM_MED=1.2, 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 N2313txSmN9B for <notmuch@notmuchmail.org>;\r
+ Tue, 6 May 2014 00:44:25 -0700 (PDT)\r
+Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
+ (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 798A5431FAE\r
+ for <notmuch@notmuchmail.org>; Tue, 6 May 2014 00:44:25 -0700 (PDT)\r
+Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
+ by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
+ (envelope-from <m.walters@qmul.ac.uk>)\r
+ id 1Wha30-0005M9-FC; Tue, 06 May 2014 08:44:21 +0100\r
+Received: from 92.40.112.41.threembb.co.uk ([92.40.112.41] helo=localhost)\r
+ by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71)\r
+ (envelope-from <m.walters@qmul.ac.uk>)\r
+ id 1Wha2x-0006l6-4N; Tue, 06 May 2014 08:44:18 +0100\r
+From: Mark Walters <markwalters1009@gmail.com>\r
+To: Jani Nikula <jani@nikula.org>, Carl Worth <cworth@cworth.org>,\r
+ David Mazieres expires 2014-08-01 PDT\r
+ <mazieres-m3ssd5tf29djdm7jf9qfi4atf2@temporary-address.scs.stanford.edu>\r
+Subject: Re: folder and path completely broken in HEAD?\r
+In-Reply-To: <87bnvb4zyh.fsf@nikula.org>\r
+References: <87oazfo3w2.fsf@ta.scs.stanford.edu> <87zjiz8hft.fsf@qmul.ac.uk>\r
+ <87iopmonzn.fsf@ta.scs.stanford.edu> <87tx96ycja.fsf@nikula.org>\r
+ <8738gqnx6k.fsf@ta.scs.stanford.edu>\r
+ <87mwewkjzu.fsf@yoom.home.cworth.org> <87bnvb4zyh.fsf@nikula.org>\r
+User-Agent: Notmuch/0.15.2+615~g78e3a93 (http://notmuchmail.org) Emacs/23.4.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Tue, 06 May 2014 08:44:07 +0100\r
+Message-ID: <871tw74aig.fsf@qmul.ac.uk>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+X-Sender-Host-Address: 92.40.112.41\r
+X-QM-Geographic: According to ripencc,\r
+ this message was delivered by a machine in Britain (UK) (GB).\r
+X-QM-SPAM-Info: Sender has good ham record. :)\r
+X-QM-Body-MD5: 9f597567ddabd8b8b93253118cf76743 (of first 20000 bytes)\r
+X-SpamAssassin-Score: 0.0\r
+X-SpamAssassin-SpamBar: /\r
+X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
+ determine if it is\r
+ spam. We require at least 5.0 points to mark a message as spam.\r
+ This message scored 0.0 points. Summary of the scoring: \r
+ * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
+ provider * (markwalters1009[at]gmail.com)\r
+ * -0.0 AWL AWL: From: address is in the auto white-list\r
+X-QM-Scan-Virus: ClamAV says the message is clean\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: Tue, 06 May 2014 07:44:29 -0000\r
+\r
+\r
+On Mon, 05 May 2014, Jani Nikula <jani@nikula.org> wrote:\r
+> Hi Carl -\r
+>\r
+> On Tue, 06 May 2014, Carl Worth <cworth@cworth.org> wrote:\r
+>> dm-list-email-notmuch@scs.stanford.edu writes:\r
+>>> However, currently it seems strange that there are *two* different\r
+>>> search terms (folder and path), and that neither one lets you search for\r
+>>> a portion of your folder name.\r
+>>\r
+>> For what it's worth, I totally agree. I'm guilty as far as sitting out\r
+>> of the detailed design discussions, (I don't use any sort of\r
+>> folder-based searching, so I don't care too much). I was aware of the\r
+>> problems of the original "folder:" code I wrote, and I was happy to hear\r
+>> that people were addressing those problems.\r
+>>\r
+>> But it's terribly strange to me that notmuch now has two different\r
+>> search terms that overlap so much in functionality. I know that I will\r
+>> never trust myself to be able to distinguish/describe the folder:\r
+>> vs. path: semantics without consulting the documentation. And that's\r
+>> discouraging.\r
+>\r
+> The discussions about this were lengthy and tedious, and I was glad we\r
+> eventually reached some consensus about what we wanted. It's always\r
+> disappointing to find out one hasn't found the solution to satisfy\r
+> everyone, but in the end I think I'm happier we were able to reach a\r
+> decision, do something about the real issues people were facing with\r
+> folder: and move on, rather than just grind to a halt. I think we were\r
+> pretty close to everyone just dropping the ball and letting the folder:\r
+> prefix be, warts and all.\r
+\r
+I would just like to second what Jani said. There was a lot of\r
+discussion and, at the time, the outcome covered all use cases that\r
+anyone showed any sign of wanting. And these included things like\r
+distinguishing between messages in cur or new or the toplevel of a maildir,\r
+wanting to search all subdirectories of a particular path (if eg the\r
+main mail folder is split into 256 subsirectories 00..ff).\r
+\r
+> The idea of path: is that it's the exact filesystem directory, relative\r
+> from the maildir root, with an rsync like ** syntax for recursive\r
+> matching. Turns out people want folder: to hide maildir implementation\r
+> details like cur and new. These are not compatible, or you need to add a\r
+> syntax that's not easy or discoverable.\r
+>\r
+> path: is now pretty much complete, and allows one to do robust scripting\r
+> that won't break in surprising ways. folder: is something we can still\r
+> add new functionality into, for example fancier interpretations of\r
+> maildir++, or anchoring if we ever get the custom query parser.\r
+>\r
+>> I think the original "folder:" shortcomings could have been addressed\r
+>> without adding two terms, and also without losing some functionality,\r
+>> (as shown in David's use case).\r
+>>\r
+>> I would have liked to have seen some explicit syntax for anchoring the\r
+>> beginning and end of the directory name, (which could have then been\r
+>> re-used for anchoring subject: or even some future header: prefix).\r
+>\r
+> As I understood it, that would have required writing a custom query\r
+> parser, a significant effort. At least nobody came up with a scheme to\r
+> do the anchoring without the parser while addressing the other issues\r
+> with the old folder: prefix.\r
+>\r
+>> I've always thought that the "cur" and "new" directories were somewhere\r
+>> on the spectrum between pointless and annoying. The idea with the\r
+>> original "folder:" indexing was to implicitly ignore these, (when both\r
+>> existed).\r
+\r
+I think many of us would agree, but there were users who wanted to\r
+distinguish new and cur, and in at least one case, the toplevel as well.\r
+\r
+\r
+>>\r
+>> It seems that the new "folder:" continues this idea, while the new\r
+>> "path:" does not.\r
+>\r
+> Correct.\r
+>\r
+>> Meanwhile, the new "folder:" anchors the search to the beginning of\r
+>> the directory, while "path:" does not.\r
+>\r
+> Incorrect (or I don't understand you).\r
+>\r
+>> And finally, "path:" adds a magic syntax to do hierarchical matching\r
+>> while "folder:" does not.\r
+>\r
+> Correct.\r
+>\r
+>> That's an odd hodgepodge of non-orthogonal distinction in\r
+>> functionality.\r
+\r
+>\r
+> I'm sorry to hear you think that way. One is verbatim filesystem path,\r
+> the other hides mail store folder implementation details as a\r
+> convenience.\r
+\r
+I think it is unfortunate that we need two variants, but I think they do\r
+do different things. Also, I think any single user will find one matches\r
+their setup and use that one essentially exclusively: if everything is\r
+in maildirs then you probably want folder:, if you want exact control\r
+then use path:.\r
+\r
+Indeed, it may be that a third option of roughly a maildir++: search term\r
+might solve David's use case.\r
+\r
+Best wishes\r
+\r
+Mark\r
+\r
+\r
projects / notmuch-archives.git / commitdiff