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