From 06224c9f388fbdd6fa71f815c04ad07d7e636cfc Mon Sep 17 00:00:00 2001 From: Mark Walters Date: Tue, 6 May 2014 08:44:07 +0100 Subject: [PATCH] Re: folder and path completely broken in HEAD? --- d0/b71c340ace41dba0cf3ef2912617a2ee6b9b18 | 185 ++++++++++++++++++++++ 1 file changed, 185 insertions(+) create mode 100644 d0/b71c340ace41dba0cf3ef2912617a2ee6b9b18 diff --git a/d0/b71c340ace41dba0cf3ef2912617a2ee6b9b18 b/d0/b71c340ace41dba0cf3ef2912617a2ee6b9b18 new file mode 100644 index 000000000..b042b6c94 --- /dev/null +++ b/d0/b71c340ace41dba0cf3ef2912617a2ee6b9b18 @@ -0,0 +1,185 @@ +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 3D2CE431FB6 + for ; Tue, 6 May 2014 00:44:29 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0.502 +X-Spam-Level: +X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 + tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, + NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_LOW=-0.7] 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 N2313txSmN9B for ; + Tue, 6 May 2014 00:44:25 -0700 (PDT) +Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6]) + (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 798A5431FAE + for ; Tue, 6 May 2014 00:44:25 -0700 (PDT) +Received: from smtp.qmul.ac.uk ([138.37.6.40]) + by mail2.qmul.ac.uk with esmtp (Exim 4.71) + (envelope-from ) + id 1Wha30-0005M9-FC; Tue, 06 May 2014 08:44:21 +0100 +Received: from 92.40.112.41.threembb.co.uk ([92.40.112.41] helo=localhost) + by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) + (envelope-from ) + id 1Wha2x-0006l6-4N; Tue, 06 May 2014 08:44:18 +0100 +From: Mark Walters +To: Jani Nikula , Carl Worth , + David Mazieres expires 2014-08-01 PDT + +Subject: Re: folder and path completely broken in HEAD? +In-Reply-To: <87bnvb4zyh.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> + <8738gqnx6k.fsf@ta.scs.stanford.edu> + <87mwewkjzu.fsf@yoom.home.cworth.org> <87bnvb4zyh.fsf@nikula.org> +User-Agent: Notmuch/0.15.2+615~g78e3a93 (http://notmuchmail.org) Emacs/23.4.1 + (x86_64-pc-linux-gnu) +Date: Tue, 06 May 2014 08:44:07 +0100 +Message-ID: <871tw74aig.fsf@qmul.ac.uk> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Sender-Host-Address: 92.40.112.41 +X-QM-Geographic: According to ripencc, + this message was delivered by a machine in Britain (UK) (GB). +X-QM-SPAM-Info: Sender has good ham record. :) +X-QM-Body-MD5: 9f597567ddabd8b8b93253118cf76743 (of first 20000 bytes) +X-SpamAssassin-Score: 0.0 +X-SpamAssassin-SpamBar: / +X-SpamAssassin-Report: The QM spam filters have analysed this message to + determine if it is + spam. We require at least 5.0 points to mark a message as spam. + This message scored 0.0 points. Summary of the scoring: + * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail + provider * (markwalters1009[at]gmail.com) + * -0.0 AWL AWL: From: address is in the auto white-list +X-QM-Scan-Virus: ClamAV says the message is clean +Cc: notmuch@notmuchmail.org +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Tue, 06 May 2014 07:44:29 -0000 + + +On Mon, 05 May 2014, Jani Nikula wrote: +> Hi Carl - +> +> On Tue, 06 May 2014, Carl Worth wrote: +>> dm-list-email-notmuch@scs.stanford.edu writes: +>>> 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. +>> +>> For what it's worth, I totally agree. I'm guilty as far as sitting out +>> of the detailed design discussions, (I don't use any sort of +>> folder-based searching, so I don't care too much). I was aware of the +>> problems of the original "folder:" code I wrote, and I was happy to hear +>> that people were addressing those problems. +>> +>> But it's terribly strange to me that notmuch now has two different +>> search terms that overlap so much in functionality. I know that I will +>> never trust myself to be able to distinguish/describe the folder: +>> vs. path: semantics without consulting the documentation. And that's +>> discouraging. +> +> The discussions about this were lengthy and tedious, and I was glad we +> eventually reached some consensus about what we wanted. It's always +> disappointing to find out one hasn't found the solution to satisfy +> everyone, but in the end I think I'm happier we were able to reach a +> decision, do something about the real issues people were facing with +> folder: and move on, rather than just grind to a halt. I think we were +> pretty close to everyone just dropping the ball and letting the folder: +> prefix be, warts and all. + +I would just like to second what Jani said. There was a lot of +discussion and, at the time, the outcome covered all use cases that +anyone showed any sign of wanting. And these included things like +distinguishing between messages in cur or new or the toplevel of a maildir, +wanting to search all subdirectories of a particular path (if eg the +main mail folder is split into 256 subsirectories 00..ff). + +> The idea of path: is that it's the exact filesystem directory, relative +> from the maildir root, with an rsync like ** syntax for recursive +> matching. Turns out people want folder: to hide maildir implementation +> details like cur and new. These are not compatible, or you need to add a +> syntax that's not easy or discoverable. +> +> path: is now pretty much complete, and allows one to do robust scripting +> that won't break in surprising ways. folder: is something we can still +> add new functionality into, for example fancier interpretations of +> maildir++, or anchoring if we ever get the custom query parser. +> +>> I think the original "folder:" shortcomings could have been addressed +>> without adding two terms, and also without losing some functionality, +>> (as shown in David's use case). +>> +>> I would have liked to have seen some explicit syntax for anchoring the +>> beginning and end of the directory name, (which could have then been +>> re-used for anchoring subject: or even some future header: prefix). +> +> As I understood it, that would have required writing a custom query +> parser, a significant effort. At least nobody came up with a scheme to +> do the anchoring without the parser while addressing the other issues +> with the old folder: prefix. +> +>> I've always thought that the "cur" and "new" directories were somewhere +>> on the spectrum between pointless and annoying. The idea with the +>> original "folder:" indexing was to implicitly ignore these, (when both +>> existed). + +I think many of us would agree, but there were users who wanted to +distinguish new and cur, and in at least one case, the toplevel as well. + + +>> +>> It seems that the new "folder:" continues this idea, while the new +>> "path:" does not. +> +> Correct. +> +>> Meanwhile, the new "folder:" anchors the search to the beginning of +>> the directory, while "path:" does not. +> +> Incorrect (or I don't understand you). +> +>> And finally, "path:" adds a magic syntax to do hierarchical matching +>> while "folder:" does not. +> +> Correct. +> +>> That's an odd hodgepodge of non-orthogonal distinction in +>> functionality. + +> +> I'm sorry to hear you think that way. One is verbatim filesystem path, +> the other hides mail store folder implementation details as a +> convenience. + +I think it is unfortunate that we need two variants, but I think they do +do different things. Also, I think any single user will find one matches +their setup and use that one essentially exclusively: if everything is +in maildirs then you probably want folder:, if you want exact control +then use path:. + +Indeed, it may be that a third option of roughly a maildir++: search term +might solve David's use case. + +Best wishes + +Mark + + -- 2.26.2