d0/b71c340ace41dba0cf3ef2912617a2ee6b9b18

   1 Return-Path: <m.walters@qmul.ac.uk>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 3D2CE431FB6\r
   6         for <notmuch@notmuchmail.org>; Tue,  6 May 2014 00:44:29 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0.502\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.502 tagged_above=-999 required=5\r
  12         tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
  13         NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id N2313txSmN9B for <notmuch@notmuchmail.org>;\r
  17         Tue,  6 May 2014 00:44:25 -0700 (PDT)\r
  18 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
  19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 798A5431FAE\r
  22         for <notmuch@notmuchmail.org>; Tue,  6 May 2014 00:44:25 -0700 (PDT)\r
  23 Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
  24         by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
  25         (envelope-from <m.walters@qmul.ac.uk>)\r
  26         id 1Wha30-0005M9-FC; Tue, 06 May 2014 08:44:21 +0100\r
  27 Received: from 92.40.112.41.threembb.co.uk ([92.40.112.41] helo=localhost)\r
  28         by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71)\r
  29         (envelope-from <m.walters@qmul.ac.uk>)\r
  30         id 1Wha2x-0006l6-4N; Tue, 06 May 2014 08:44:18 +0100\r
  31 From: Mark Walters <markwalters1009@gmail.com>\r
  32 To: Jani Nikula <jani@nikula.org>, Carl Worth <cworth@cworth.org>,\r
  33         David Mazieres expires 2014-08-01 PDT\r
  34         <mazieres-m3ssd5tf29djdm7jf9qfi4atf2@temporary-address.scs.stanford.edu>\r
  35 Subject: Re: folder and path completely broken in HEAD?\r
  36 In-Reply-To: <87bnvb4zyh.fsf@nikula.org>\r
  37 References: <87oazfo3w2.fsf@ta.scs.stanford.edu> <87zjiz8hft.fsf@qmul.ac.uk>\r
  38         <87iopmonzn.fsf@ta.scs.stanford.edu> <87tx96ycja.fsf@nikula.org>\r
  39         <8738gqnx6k.fsf@ta.scs.stanford.edu>\r
  40         <87mwewkjzu.fsf@yoom.home.cworth.org> <87bnvb4zyh.fsf@nikula.org>\r
  41 User-Agent: Notmuch/0.15.2+615~g78e3a93 (http://notmuchmail.org) Emacs/23.4.1\r
  42         (x86_64-pc-linux-gnu)\r
  43 Date: Tue, 06 May 2014 08:44:07 +0100\r
  44 Message-ID: <871tw74aig.fsf@qmul.ac.uk>\r
  45 MIME-Version: 1.0\r
  46 Content-Type: text/plain; charset=us-ascii\r
  47 X-Sender-Host-Address: 92.40.112.41\r
  48 X-QM-Geographic: According to ripencc,\r
  49         this message was delivered by a machine in Britain (UK) (GB).\r
  50 X-QM-SPAM-Info: Sender has good ham record.  :)\r
  51 X-QM-Body-MD5: 9f597567ddabd8b8b93253118cf76743 (of first 20000 bytes)\r
  52 X-SpamAssassin-Score: 0.0\r
  53 X-SpamAssassin-SpamBar: /\r
  54 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
  55         determine if it is\r
  56         spam. We require at least 5.0 points to mark a message as spam.\r
  57         This message scored 0.0 points. Summary of the scoring: \r
  58         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
  59         provider *      (markwalters1009[at]gmail.com)\r
  60         * -0.0 AWL AWL: From: address is in the auto white-list\r
  61 X-QM-Scan-Virus: ClamAV says the message is clean\r
  62 Cc: notmuch@notmuchmail.org\r
  63 X-BeenThere: notmuch@notmuchmail.org\r
  64 X-Mailman-Version: 2.1.13\r
  65 Precedence: list\r
  66 List-Id: "Use and development of the notmuch mail system."\r
  67         <notmuch.notmuchmail.org>\r
  68 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  69         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  70 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  71 List-Post: <mailto:notmuch@notmuchmail.org>\r
  72 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  73 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  74         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  75 X-List-Received-Date: Tue, 06 May 2014 07:44:29 -0000\r
  76 \r
  77 \r
  78 On Mon, 05 May 2014, Jani Nikula <jani@nikula.org> wrote:\r
  79 > Hi Carl -\r
  80 >\r
  81 > On Tue, 06 May 2014, Carl Worth <cworth@cworth.org> wrote:\r
  82 >> dm-list-email-notmuch@scs.stanford.edu writes:\r
  83 >>> However, currently it seems strange that there are *two* different\r
  84 >>> search terms (folder and path), and that neither one lets you search for\r
  85 >>> a portion of your folder name.\r
  86 >>\r
  87 >> For what it's worth, I totally agree. I'm guilty as far as sitting out\r
  88 >> of the detailed design discussions, (I don't use any sort of\r
  89 >> folder-based searching, so I don't care too much). I was aware of the\r
  90 >> problems of the original "folder:" code I wrote, and I was happy to hear\r
  91 >> that people were addressing those problems.\r
  92 >>\r
  93 >> But it's terribly strange to me that notmuch now has two different\r
  94 >> search terms that overlap so much in functionality. I know that I will\r
  95 >> never trust myself to be able to distinguish/describe the folder:\r
  96 >> vs. path: semantics without consulting the documentation. And that's\r
  97 >> discouraging.\r
  98 >\r
  99 > The discussions about this were lengthy and tedious, and I was glad we\r
 100 > eventually reached some consensus about what we wanted. It's always\r
 101 > disappointing to find out one hasn't found the solution to satisfy\r
 102 > everyone, but in the end I think I'm happier we were able to reach a\r
 103 > decision, do something about the real issues people were facing with\r
 104 > folder: and move on, rather than just grind to a halt. I think we were\r
 105 > pretty close to everyone just dropping the ball and letting the folder:\r
 106 > prefix be, warts and all.\r
 107 \r
 108 I would just like to second what Jani said. There was a lot of\r
 109 discussion and, at the time, the outcome covered all use cases that\r
 110 anyone showed any sign of wanting. And these included things like\r
 111 distinguishing between messages in cur or new or the toplevel of a maildir,\r
 112 wanting to search all subdirectories of a particular path (if eg the\r
 113 main mail folder is split into 256 subsirectories 00..ff).\r
 114 \r
 115 > The idea of path: is that it's the exact filesystem directory, relative\r
 116 > from the maildir root, with an rsync like ** syntax for recursive\r
 117 > matching. Turns out people want folder: to hide maildir implementation\r
 118 > details like cur and new. These are not compatible, or you need to add a\r
 119 > syntax that's not easy or discoverable.\r
 120 >\r
 121 > path: is now pretty much complete, and allows one to do robust scripting\r
 122 > that won't break in surprising ways. folder: is something we can still\r
 123 > add new functionality into, for example fancier interpretations of\r
 124 > maildir++, or anchoring if we ever get the custom query parser.\r
 125 >\r
 126 >> I think the original "folder:" shortcomings could have been addressed\r
 127 >> without adding two terms, and also without losing some functionality,\r
 128 >> (as shown in David's use case).\r
 129 >>\r
 130 >> I would have liked to have seen some explicit syntax for anchoring the\r
 131 >> beginning and end of the directory name, (which could have then been\r
 132 >> re-used for anchoring subject: or even some future header: prefix).\r
 133 >\r
 134 > As I understood it, that would have required writing a custom query\r
 135 > parser, a significant effort. At least nobody came up with a scheme to\r
 136 > do the anchoring without the parser while addressing the other issues\r
 137 > with the old folder: prefix.\r
 138 >\r
 139 >> I've always thought that the "cur" and "new" directories were somewhere\r
 140 >> on the spectrum between pointless and annoying. The idea with the\r
 141 >> original "folder:" indexing was to implicitly ignore these, (when both\r
 142 >> existed).\r
 143 \r
 144 I think many of us would agree, but there were users who wanted to\r
 145 distinguish new and cur, and in at least one case, the toplevel as well.\r
 146 \r
 147 \r
 148 >>\r
 149 >> It seems that the new "folder:" continues this idea, while the new\r
 150 >> "path:" does not.\r
 151 >\r
 152 > Correct.\r
 153 >\r
 154 >> Meanwhile, the new "folder:" anchors the search to the beginning of\r
 155 >> the directory, while "path:" does not.\r
 156 >\r
 157 > Incorrect (or I don't understand you).\r
 158 >\r
 159 >> And finally, "path:" adds a magic syntax to do hierarchical matching\r
 160 >> while "folder:" does not.\r
 161 >\r
 162 > Correct.\r
 163 >\r
 164 >> That's an odd hodgepodge of non-orthogonal distinction in\r
 165 >> functionality.\r
 166 \r
 167 >\r
 168 > I'm sorry to hear you think that way. One is verbatim filesystem path,\r
 169 > the other hides mail store folder implementation details as a\r
 170 > convenience.\r
 171 \r
 172 I think it is unfortunate that we need two variants, but I think they do\r
 173 do different things. Also, I think any single user will find one matches\r
 174 their setup and use that one essentially exclusively: if everything is\r
 175 in maildirs then you probably want folder:, if you want exact control\r
 176 then use path:.\r
 177 \r
 178 Indeed, it may be that a third option of roughly a maildir++: search term\r
 179 might solve David's use case.\r
 180 \r
 181 Best wishes\r
 182 \r
 183 Mark\r
 184 \r
 185 \r