From b2ba2ae902a22723c968de385948415ee6be5e02 Mon Sep 17 00:00:00 2001 From: Mark Walters Date: Wed, 7 May 2014 20:24:33 +0100 Subject: [PATCH] Re: folder and path completely broken in HEAD? --- e0/16ac7373443713889c29e193ba6a49a1f74ecd | 177 ++++++++++++++++++++++ 1 file changed, 177 insertions(+) create mode 100644 e0/16ac7373443713889c29e193ba6a49a1f74ecd diff --git a/e0/16ac7373443713889c29e193ba6a49a1f74ecd b/e0/16ac7373443713889c29e193ba6a49a1f74ecd new file mode 100644 index 000000000..25896870c --- /dev/null +++ b/e0/16ac7373443713889c29e193ba6a49a1f74ecd @@ -0,0 +1,177 @@ +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 12AE7431FAF + for ; Wed, 7 May 2014 12:24:48 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 1.202 +X-Spam-Level: * +X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 + tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, + NML_ADSP_CUSTOM_MED=1.2] 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 a1uLPMa0VxNX for ; + Wed, 7 May 2014 12:24:43 -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 B9187431FAE + for ; Wed, 7 May 2014 12:24:43 -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 1Wi7SF-00078x-DJ; Wed, 07 May 2014 20:24:37 +0100 +Received: from 5751dfa2.skybroadband.com ([87.81.223.162] helo=localhost) + by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) + (envelope-from ) + id 1Wi7SE-0000zr-V0; Wed, 07 May 2014 20:24:35 +0100 +From: Mark Walters +To: Carl Worth , Jani Nikula , + David Mazieres expires 2014-08-01 PDT + +Subject: Re: folder and path completely broken in HEAD? +In-Reply-To: <87eh06jngf.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> + <87bnvb4zyh.fsf@nikula.org> <871tw74aig.fsf@qmul.ac.uk> + <87eh06jngf.fsf@yoom.home.cworth.org> +User-Agent: Notmuch/0.15.2+615~g78e3a93 (http://notmuchmail.org) Emacs/23.4.1 + (x86_64-pc-linux-gnu) +Date: Wed, 07 May 2014 20:24:33 +0100 +Message-ID: <8738glmlxq.fsf@qmul.ac.uk> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Sender-Host-Address: 87.81.223.162 +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: e1edccd7297366d2f34c9a3bdae45a5b (of first 20000 bytes) +X-SpamAssassin-Score: -0.1 +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.1 points. + Summary of the scoring: + * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail + provider * (markwalters1009[at]gmail.com) + * -0.1 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: Wed, 07 May 2014 19:24:48 -0000 + + +> The trick here is that it's easy to miss people who are happy with +> current functionality. Adding functionality to address newly-identified +> use cases makes a lot of sense. But removing functionality runs the risk +> of only discovering that people were relying on it after the fact, +> (Which seems to have happened here). + +Yes indeed. I think one thing that I, at least, hadn't realised is that +people have lots of strange mail layouts often to work around problems +in mail agents (notmuch or others) or filesystem limitations etc. + +>>> 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. +> +> This definition of "path:" seems good. It covers a lot of cases that the +> original "folder:" did not and allows precise, predictable control. +> +>>> Turns out people want folder: to hide maildir implementation +>>> details like cur and new. +> +> Which is something that "folder:" always did. +> +>>> These are not compatible, or you need to add a syntax that's not easy +>>> or discoverable. +> +> OK. So I won't argue that we don't need two different syntaxes here. But +> I will continue to discuss a use case that was addressed before and is +> no longer. +> +>> 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. +> +> So now, "path:" allows for that, right? +> +> My concern is not so much that "path:" was added to address new things, +> but more than "folder:" was modified in a way that dropped useful +> functionality, (beyond just fixing bugs in "folder:" such as the +> accidental support of stemming). + +One possibly perverse remark: it wouldn't surprise me if someone +actually used the stemming. I have used folders called old older and +oldest and that probably can be excluded by stemming..... + +All I am really saying is that any change we made was going to break +some people's setups. + +>> I think it is unfortunate that we need two variants, but I think they do +>> do different things. +> +> I'll accept that. +> +> But, while I have heard a good definition of "path:", (see above), I +> haven't heard a good one for "folder:" yet. Can you provide that? + +I think folder:foo/bar means "In the maildir exactly foo/bar" + +>> Also, I think any single user will find one matches their setup and +>> use that one essentially exclusively: +> +> The current discussion is evidence against that. We have a user of +> folder: that can no longer get at the desired functionality, (that used +> to exist). + +Sorry I wasn't trying to suggest that the current setup does everything +people want (clearly not!): just answering your question about the +differences being confusing. since each user will probably only use one +of them they probably become accustomed to its use. + +Indeed, I think of the choice as being analogous to allowing the user to +choose which path scheme they like (so sort of like a customisation): +maildir folder based or filesystem path based. + +>> Indeed, it may be that a third option of roughly a maildir++: search term +>> might solve David's use case. +> +> Or just making "folder:" index each term of a filesytem path like it +> used to do. And if that doesn't give sufficient control to some users, +> then "path:" is available. + +We could do this. It might break things for user who are using the new +syntax.... Maybe we could make an initial / match the root of the +maildir store. But I think some people will dislike any of the options. + +> +> I've already lost what I would have preferred, (a single syntax for all +> use cases---which was lost not to a design problem, but simply the +> implementation difficulty of requiring a custom query parser). I really +> would not like to see things continue down to have a *third* syntax. + +So this third syntax would fit with my view of it being a customisation +like thing. + +Best wishes + +Mark + -- 2.26.2