3d/4701949c608decda984d69bdcab57c6d4f7029

   1 Return-Path: <amdragon@mit.edu>\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 C951B431FD0\r
   6         for <notmuch@notmuchmail.org>; Wed,  2 Feb 2011 22:14:33 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_NONE=-0.0001] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id ahCKLzqokZ5M for <notmuch@notmuchmail.org>;\r
  16         Wed,  2 Feb 2011 22:14:32 -0800 (PST)\r
  17 Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU\r
  18         [18.7.68.34])\r
  19         by olra.theworths.org (Postfix) with ESMTP id BE93B431FB5\r
  20         for <notmuch@notmuchmail.org>; Wed,  2 Feb 2011 22:14:32 -0800 (PST)\r
  21 X-AuditID: 12074422-b7c3eae000000a70-41-4d4a47c8c503\r
  22 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39])\r
  23         by dmz-mailsec-scanner-5.mit.edu (Symantec Brightmail Gateway) with\r
  24         SMTP id F7.53.02672.8C74A4D4; Thu,  3 Feb 2011 01:14:32 -0500 (EST)\r
  25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
  26         by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p136EV2g030981; \r
  27         Thu, 3 Feb 2011 01:14:31 -0500\r
  28 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
  29         (authenticated bits=0)\r
  30         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
  31         by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p136ET2e001049\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Thu, 3 Feb 2011 01:14:29 -0500 (EST)\r
  34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.72)\r
  35         (envelope-from <amdragon@mit.edu>)\r
  36         id 1PksSb-0006Vo-3J; Thu, 03 Feb 2011 01:14:29 -0500\r
  37 Date: Thu, 3 Feb 2011 01:14:29 -0500\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: Carl Worth <cworth@cworth.org>\r
  40 Subject: Folder search semantics (was Re: [RFC PATCH v2 0/8] Custom query\r
  41         parser, date search, folder search, and more)\r
  42 Message-ID: <20110203061429.GD28537@mit.edu>\r
  43 References: <1295165458-9573-1-git-send-email-amdragon@mit.edu>\r
  44         <20110202050336.GB28537@mit.edu>\r
  45         <87sjw6hx2l.fsf@yoom.home.cworth.org>\r
  46 MIME-Version: 1.0\r
  47 Content-Type: text/plain; charset=us-ascii\r
  48 Content-Disposition: inline\r
  49 In-Reply-To: <87sjw6hx2l.fsf@yoom.home.cworth.org>\r
  50 User-Agent: Mutt/1.5.20 (2009-06-14)\r
  51 X-Brightmail-Tracker: AAAAAA==\r
  52 Cc: notmuch@notmuchmail.org\r
  53 X-BeenThere: notmuch@notmuchmail.org\r
  54 X-Mailman-Version: 2.1.13\r
  55 Precedence: list\r
  56 List-Id: "Use and development of the notmuch mail system."\r
  57         <notmuch.notmuchmail.org>\r
  58 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  59         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  60 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  61 List-Post: <mailto:notmuch@notmuchmail.org>\r
  62 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  63 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  64         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  65 X-List-Received-Date: Thu, 03 Feb 2011 06:14:34 -0000\r
  66 \r
  67 Quoth Carl Worth on Feb 02 at  2:48 pm:\r
  68 > Restricting my reply to one tiny bit of your mail:\r
  69 > \r
  70 > You wrote:\r
  71 > > non-recursive is the only thing that makes sense for Maildir++ folders\r
  72 > \r
  73 > Either I'm not understanding Maildir++ folders, or I don't agree with\r
  74 > you.\r
  75 > \r
  76 > I might have an email archive that looks like this:\r
  77 > \r
  78 >   Maildir\r
  79 >     .work\r
  80 >       .project1\r
  81 >       .project2\r
  82 >       .etc...\r
  83 >     .family\r
  84 >       .dad\r
  85 >       .mom\r
  86 >       .brother\r
  87 >       .etc...\r
  88 > \r
  89 > With the above setup, what would be unreasonable about wanting to search\r
  90 > for all work-related messages (across all projects, say) with a string\r
  91 > like "folder:work" ?\r
  92 > \r
  93 > Now, a person might definitely want to search for messages in the\r
  94 > ".work" folder directly, (not including the sub-folders), so we should\r
  95 > provide support for users to get at that behavior as well, (such as a\r
  96 > proposed "folder:work$" or so).\r
  97 > \r
  98 > To me, both cases are perfectly legitimate, and I don't understand an\r
  99 > argument that claims that only one makes sense. (Or again, I may be\r
 100 > misunderstanding something.)\r
 101 \r
 102 (Somebody with more first-hand Maildir++ experience should jump in here.\r
 103 I stopped using Maildir++ a long time ago, so I may have no idea what\r
 104 I'm talking about.)\r
 105 \r
 106 Both cases are perfectly legitimate.\r
 107 \r
 108 However, the issue with Maildir++ is that the inbox is stored in the\r
 109 top-level directory:\r
 110 \r
 111   Maildir\r
 112     cur\r
 113     new\r
 114     tmp\r
 115     .work\r
 116     .work.project1\r
 117 \r
 118 As a consequence, all folders are subfolders of the inbox.  With\r
 119 recursive search, a search for your inbox folder returns *all* of your\r
 120 messages.  I wasn't trying to say that we shouldn't support recursive\r
 121 search (I'm all for flexibility), but it's a confusing default for\r
 122 Maildir++ because of this.\r
 123 \r
 124 Maildir++ has the added twist that the inbox folder has no name.  As a\r
 125 result, currently notmuch can't search for a Maildir++ inbox folder,\r
 126 which needs to be addressed somehow.  The least surprising approach\r
 127 would compatibility with the Maildir++ convention of calling the\r
 128 top-level folder INBOX, the subfolder INBOX.work, etc.\r
 129 \r
 130 \r
 131 Maildir++ issues aside, I submit that rooted, non-recursive folder\r
 132 searches are a more natural default with a more conventional syntactic\r
 133 extension to non-rooted/recursive searches.  In\r
 134 id:87aaiy3u65.fsf@yoom.home.cworth.org, you mentioned that you\r
 135 implemented non-rooted folder search to mimic subject search.  But file\r
 136 system paths are not natural language like subject lines.  File system\r
 137 paths are hierarchical and rooted.\r
 138 \r
 139 Of course, special query operators like ^ and $ can mitigate this, but\r
 140 these queries *aren't* regexps and, furthermore, people don't usually\r
 141 apply regexps to file names.  They apply globs.  Glob syntax has the\r
 142 added benefit of congruity with Xapian wildcard syntax.  This naturally\r
 143 leads to a rooted, non-recursive syntax by default (like globs), where a\r
 144 * at the end means recursive and a * at the beginning means non-rooted.\r
 145 In fact, we could easily generalize this to arbitrary shell globs.\r
 146 \r
 147 \r
 148 Here's a proposal that, I think, addresses Maildir++ inboxes and\r
 149 subfolders; rooted, non-rooted, recursive, and non-recursive queries;\r
 150 and then some.  Plus, it wouldn't require many code changes; you've\r
 151 already done the hard work.\r
 152 \r
 153 Switch XFOLDER from a probabilistic prefix with word-splitting to a\r
 154 boolean prefix without word-splitting.  When indexing, strip off the cur\r
 155 or new and examine the resulting directory name.  If it's the mail root,\r
 156 this is a Maildir++ inbox, so add the term XFOLDERINBOX.  If it starts\r
 157 with a dot, it's a Maildir++ subfolder, so add the term\r
 158 XFOLDERINBOX<.dirname>.  Otherwise, add the term XFOLDER<dirname>.\r
 159 Then, using a custom query transform for the "folder:" prefix, enumerate\r
 160 XFOLDER terms and form a synonym query out of those that fnmatch the\r
 161 user's folder query.\r