--- /dev/null
+Return-Path:\r
+ <return-xbwu4ybem5z8692z77z8q6e7q6@temporary-address.scs.stanford.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 C0BDA429E2F\r
+ for <notmuch@notmuchmail.org>; Sat, 3 May 2014 18:35:13 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.3\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_MED=-2.3] 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 z3zkJ-7cWM-J for <notmuch@notmuchmail.org>;\r
+ Sat, 3 May 2014 18:35:04 -0700 (PDT)\r
+Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10])\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 A5894431E64\r
+ for <notmuch@notmuchmail.org>; Sat, 3 May 2014 18:35:04 -0700 (PDT)\r
+Received: from market.scs.stanford.edu (localhost.scs.stanford.edu\r
+ [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id\r
+ s441Yx5p016709; Sat, 3 May 2014 18:34:59 -0700 (PDT)\r
+Received: (from dm@localhost)\r
+ by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s441YxJe001703;\r
+ Sat, 3 May 2014 18:34:59 -0700 (PDT)\r
+X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
+ return-xbwu4ybem5z8692z77z8q6e7q6@ta.scs.stanford.edu using -f\r
+From: dm-list-email-notmuch@scs.stanford.edu\r
+To: Jani Nikula <jani@nikula.org>, Mark Walters <markwalters1009@gmail.com>\r
+Subject: Re: folder and path completely broken in HEAD?\r
+In-Reply-To: <87tx96ycja.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
+Date: Sat, 03 May 2014 18:34:59 -0700\r
+Message-ID: <8738gqnx6k.fsf@ta.scs.stanford.edu>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+Reply-To: David Mazieres expires 2014-08-01 PDT\r
+ <mazieres-m3ssd5tf29djdm7jf9qfi4atf2@temporary-address.scs.stanford.edu>\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: Sun, 04 May 2014 01:35:13 -0000\r
+\r
+Jani Nikula <jani@nikula.org> writes:\r
+\r
+> It's not going to help you, but I'll mention a few of the issues the old\r
+> folder: search had, which we also had complaints about, and which would\r
+> have been quite hard to fix while preserving the behaviour you want. In\r
+> short, we considered the old folder: search broken.\r
+>\r
+> Given layout:\r
+>\r
+> Foo/{cur,new}\r
+> foo/{cur,new}\r
+> fooing/{cur,new}\r
+> bar/foo/{cur,new}\r
+> cur\r
+> new\r
+>\r
+> It was impossible to refer to the top level folder.\r
+>\r
+> It was impossible to refer to foo without also referring to Foo, fooing,\r
+> and bar/foo.\r
+>\r
+> In your layout, if you also had 2013/.bar.foo, folder:foo would match\r
+> that as well. To not match that, you would have to include each\r
+> folder:.foo.xxx in the search.\r
+\r
+First, thanks for the response. The responsiveness and friendliness of\r
+the notmuch mailing list goes a long way towards compensating for any\r
+missing features / customizability one might want.\r
+\r
+I was already aware of the issues you raise, and had worked around them\r
+by just renaming all my mail folders. I agree that searching for a\r
+particular folder is crucial functionality, and found it weird that I\r
+had to abandon my main top-level mailbox (which I just renamed\r
+.INBOX.Main).\r
+\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. Admittedly the old folder code was one\r
+of the parts of the notmuch source that didn't make sense to me (and now\r
+I'm starting to understand why--e.g., the fact that it used stemming,\r
+for instance, was just weird and maybe accidental).\r
+\r
+I may be able to hack around this problem in the emacs lisp part or with\r
+a wrapper script. I'm already having to defadvice around\r
+notmuch-call-notmuch-sexp to implement features I'm missing from\r
+wanderlust and gnus (e.g., the inability to specify regexps matching all\r
+my email addresses).\r
+\r
+But to help me understand the current design, can you answer a couple of\r
+questions?\r
+\r
+\r
+First, are there people out there who do not use a collection of maildir\r
+directories, with all mail in cur and new? If not, why does notmuch try\r
+to find mail in non-mail-directories, and why do you need search terms\r
+differentiating new and cur? Conversely, I find it particularly weird\r
+that there's no convenient way to say "stop trying to index stuff that\r
+isn't in a maildir (cur or new)." You can do the inverse and blacklist\r
+files, but then I end up with stuff like this in my .notmuch-config:\r
+\r
+ ignore=dovecot-keywords;dovecot-uidlist;dovecot-uidvalidity;dovecot.index;dovecot.index.cache;dovecot.index.log;dovecot.index.log.2;dovecot.index.search;dovecot.index.search.uids;maildirfolder;\r
+\r
+(And still I think there are other junk files that get left around by my\r
+imap server or other software, so notmuch new still repeatedly tries to\r
+index junk whenever I run it.)\r
+\r
+\r
+Second, does anyone out there have a collection with more than a few\r
+thousand maildirs? I understand some people index millions of messages,\r
+but even with tiny maildirs of a few hundred messages each, that's a\r
+mere 10,000 maildirs. So for that, who needs any kind of Xapian\r
+indexing fanciness or dedicated XFOLDER prefix? Scanning the entire set\r
+of XDIRECTORY terms to apply an arbitrary predicate should take\r
+negligible time. So all you really need is a boolean search term\r
+containing the directory docid (or with the existing schema the ability\r
+to do a prefix search on XFDIRENTRYn:*).\r
+\r
+Thanks,\r
+David\r
projects / notmuch-archives.git / commitdiff