From 68605a9fe440d6e08bdb3e2bdda79abfa858d3a7 Mon Sep 17 00:00:00 2001 From: Jani Nikula Date: Tue, 6 May 2014 01:34:30 +0300 Subject: [PATCH] Re: folder and path completely broken in HEAD? --- b4/9a87ac4e36f9851e9f5285c867fc545d89e552 | 159 ++++++++++++++++++++++ 1 file changed, 159 insertions(+) create mode 100644 b4/9a87ac4e36f9851e9f5285c867fc545d89e552 diff --git a/b4/9a87ac4e36f9851e9f5285c867fc545d89e552 b/b4/9a87ac4e36f9851e9f5285c867fc545d89e552 new file mode 100644 index 000000000..9c3e5ef56 --- /dev/null +++ b/b4/9a87ac4e36f9851e9f5285c867fc545d89e552 @@ -0,0 +1,159 @@ +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 53F93431FAF + for ; Mon, 5 May 2014 15:34:44 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -0.7 +X-Spam-Level: +X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 + tests=[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 zUAhr+1LdtU1 for ; + Mon, 5 May 2014 15:34:34 -0700 (PDT) +Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com + [74.125.83.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client + certificate requested) by olra.theworths.org (Postfix) with ESMTPS id + 4D3A5431FAE for ; Mon, 5 May 2014 15:34:34 -0700 + (PDT) +Received: by mail-ee0-f41.google.com with SMTP id t10so2245533eei.28 + for ; Mon, 05 May 2014 15:34:33 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:from:to:cc:subject:in-reply-to:references + :user-agent:date:message-id:mime-version:content-type; + bh=4jOSD4OopB7Em/lSXQHTIyjp+dE4IqwHRQaE+Hl8M9Y=; + b=ei8xSWpyrLEzYjRhM6+im94QTkHsjriMcH0XdwQYqJeIGYWRXUEnaoQCIuY1yyYI8C + kLSm9Sbe22EWV2WfXLLgcZlTMkmMgJB/zGyEctbolq21Luthl0/yl2lgNguuGjWJ2fsL + DyArTcXy6I2/5wdBB646jjbDu2apeLG9NZlUAShkIpdLQ47MnTiufzCcP1Z9pZwhmExE + PzlnYqXkl4ZYPWOkXyCbkFVZAtSIJC6fd2vcc9o6pHQGgb92mi2eCO67ibnQ3p+jxO13 + sjZ7IQYgyRMfSFsAf9+Td2NkpDR9F6munD7EUvpRhIralKLjrq4F/RVDL6fIm3s8C0m1 + dO9g== +X-Gm-Message-State: + ALoCoQk0lyuvHXM8agX/1H/waJN20uG4qPgRIFPLwDc29p7F2wnLyGmE5KECBMKF/8dJvb6eK85y +X-Received: by 10.15.50.136 with SMTP id l8mr5732323eew.73.1399329273064; + Mon, 05 May 2014 15:34:33 -0700 (PDT) +Received: from localhost (dsl-hkibrasgw2-58c36f-91.dhcp.inet.fi. + [88.195.111.91]) + by mx.google.com with ESMTPSA id 45sm33177942eeh.9.2014.05.05.15.34.31 + for + (version=TLSv1.2 cipher=RC4-SHA bits=128/128); + Mon, 05 May 2014 15:34:32 -0700 (PDT) +From: Jani Nikula +To: Carl Worth , David Mazieres expires 2014-08-01 PDT + , + Mark Walters +Subject: Re: folder and path completely broken in HEAD? +In-Reply-To: <87mwewkjzu.fsf@yoom.home.cworth.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> +User-Agent: Notmuch/0.18~rc0+2~gbc64cdc (http://notmuchmail.org) Emacs/24.3.1 + (x86_64-pc-linux-gnu) +Date: Tue, 06 May 2014 01:34:30 +0300 +Message-ID: <87bnvb4zyh.fsf@nikula.org> +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 +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Mon, 05 May 2014 22:34:44 -0000 + + +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. + +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). +> +> 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. + + +BR, +Jani. -- 2.26.2