--- /dev/null
+Return-Path: <amdragon@mit.edu>\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 C951B431FD0\r
+ for <notmuch@notmuchmail.org>; Wed, 2 Feb 2011 22:14:33 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_NONE=-0.0001] 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 ahCKLzqokZ5M for <notmuch@notmuchmail.org>;\r
+ Wed, 2 Feb 2011 22:14:32 -0800 (PST)\r
+Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU\r
+ [18.7.68.34])\r
+ by olra.theworths.org (Postfix) with ESMTP id BE93B431FB5\r
+ for <notmuch@notmuchmail.org>; Wed, 2 Feb 2011 22:14:32 -0800 (PST)\r
+X-AuditID: 12074422-b7c3eae000000a70-41-4d4a47c8c503\r
+Received: from mailhub-auth-4.mit.edu ( [18.7.62.39])\r
+ by dmz-mailsec-scanner-5.mit.edu (Symantec Brightmail Gateway) with\r
+ SMTP id F7.53.02672.8C74A4D4; Thu, 3 Feb 2011 01:14:32 -0500 (EST)\r
+Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
+ by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p136EV2g030981; \r
+ Thu, 3 Feb 2011 01:14:31 -0500\r
+Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
+ (authenticated bits=0)\r
+ (User authenticated as amdragon@ATHENA.MIT.EDU)\r
+ by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p136ET2e001049\r
+ (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
+ Thu, 3 Feb 2011 01:14:29 -0500 (EST)\r
+Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.72)\r
+ (envelope-from <amdragon@mit.edu>)\r
+ id 1PksSb-0006Vo-3J; Thu, 03 Feb 2011 01:14:29 -0500\r
+Date: Thu, 3 Feb 2011 01:14:29 -0500\r
+From: Austin Clements <amdragon@MIT.EDU>\r
+To: Carl Worth <cworth@cworth.org>\r
+Subject: Folder search semantics (was Re: [RFC PATCH v2 0/8] Custom query\r
+ parser, date search, folder search, and more)\r
+Message-ID: <20110203061429.GD28537@mit.edu>\r
+References: <1295165458-9573-1-git-send-email-amdragon@mit.edu>\r
+ <20110202050336.GB28537@mit.edu>\r
+ <87sjw6hx2l.fsf@yoom.home.cworth.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Content-Disposition: inline\r
+In-Reply-To: <87sjw6hx2l.fsf@yoom.home.cworth.org>\r
+User-Agent: Mutt/1.5.20 (2009-06-14)\r
+X-Brightmail-Tracker: AAAAAA==\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: Thu, 03 Feb 2011 06:14:34 -0000\r
+\r
+Quoth Carl Worth on Feb 02 at 2:48 pm:\r
+> Restricting my reply to one tiny bit of your mail:\r
+> \r
+> You wrote:\r
+> > non-recursive is the only thing that makes sense for Maildir++ folders\r
+> \r
+> Either I'm not understanding Maildir++ folders, or I don't agree with\r
+> you.\r
+> \r
+> I might have an email archive that looks like this:\r
+> \r
+> Maildir\r
+> .work\r
+> .project1\r
+> .project2\r
+> .etc...\r
+> .family\r
+> .dad\r
+> .mom\r
+> .brother\r
+> .etc...\r
+> \r
+> With the above setup, what would be unreasonable about wanting to search\r
+> for all work-related messages (across all projects, say) with a string\r
+> like "folder:work" ?\r
+> \r
+> Now, a person might definitely want to search for messages in the\r
+> ".work" folder directly, (not including the sub-folders), so we should\r
+> provide support for users to get at that behavior as well, (such as a\r
+> proposed "folder:work$" or so).\r
+> \r
+> To me, both cases are perfectly legitimate, and I don't understand an\r
+> argument that claims that only one makes sense. (Or again, I may be\r
+> misunderstanding something.)\r
+\r
+(Somebody with more first-hand Maildir++ experience should jump in here.\r
+I stopped using Maildir++ a long time ago, so I may have no idea what\r
+I'm talking about.)\r
+\r
+Both cases are perfectly legitimate.\r
+\r
+However, the issue with Maildir++ is that the inbox is stored in the\r
+top-level directory:\r
+\r
+ Maildir\r
+ cur\r
+ new\r
+ tmp\r
+ .work\r
+ .work.project1\r
+\r
+As a consequence, all folders are subfolders of the inbox. With\r
+recursive search, a search for your inbox folder returns *all* of your\r
+messages. I wasn't trying to say that we shouldn't support recursive\r
+search (I'm all for flexibility), but it's a confusing default for\r
+Maildir++ because of this.\r
+\r
+Maildir++ has the added twist that the inbox folder has no name. As a\r
+result, currently notmuch can't search for a Maildir++ inbox folder,\r
+which needs to be addressed somehow. The least surprising approach\r
+would compatibility with the Maildir++ convention of calling the\r
+top-level folder INBOX, the subfolder INBOX.work, etc.\r
+\r
+\r
+Maildir++ issues aside, I submit that rooted, non-recursive folder\r
+searches are a more natural default with a more conventional syntactic\r
+extension to non-rooted/recursive searches. In\r
+id:87aaiy3u65.fsf@yoom.home.cworth.org, you mentioned that you\r
+implemented non-rooted folder search to mimic subject search. But file\r
+system paths are not natural language like subject lines. File system\r
+paths are hierarchical and rooted.\r
+\r
+Of course, special query operators like ^ and $ can mitigate this, but\r
+these queries *aren't* regexps and, furthermore, people don't usually\r
+apply regexps to file names. They apply globs. Glob syntax has the\r
+added benefit of congruity with Xapian wildcard syntax. This naturally\r
+leads to a rooted, non-recursive syntax by default (like globs), where a\r
+* at the end means recursive and a * at the beginning means non-rooted.\r
+In fact, we could easily generalize this to arbitrary shell globs.\r
+\r
+\r
+Here's a proposal that, I think, addresses Maildir++ inboxes and\r
+subfolders; rooted, non-rooted, recursive, and non-recursive queries;\r
+and then some. Plus, it wouldn't require many code changes; you've\r
+already done the hard work.\r
+\r
+Switch XFOLDER from a probabilistic prefix with word-splitting to a\r
+boolean prefix without word-splitting. When indexing, strip off the cur\r
+or new and examine the resulting directory name. If it's the mail root,\r
+this is a Maildir++ inbox, so add the term XFOLDERINBOX. If it starts\r
+with a dot, it's a Maildir++ subfolder, so add the term\r
+XFOLDERINBOX<.dirname>. Otherwise, add the term XFOLDER<dirname>.\r
+Then, using a custom query transform for the "folder:" prefix, enumerate\r
+XFOLDER terms and form a synonym query out of those that fnmatch the\r
+user's folder query.\r
projects / notmuch-archives.git / commitdiff