From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 862DD431FBD for ; Sat, 25 Jan 2014 11:41:53 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 CHXqf89Bni+T for ; Sat, 25 Jan 2014 11:41:48 -0800 (PST) X-Greylist: delayed 541 seconds by postgrey-1.32 at olra; Sat, 25 Jan 2014 11:41:48 PST Received: from defaultvalue.org (defaultvalue.org [70.85.129.156]) by olra.theworths.org (Postfix) with ESMTP id 587C6431FBC for ; Sat, 25 Jan 2014 11:41:48 -0800 (PST) Received: from trouble.defaultvalue.org (localhost [127.0.0.1]) (Authenticated sender: rlb@defaultvalue.org) by defaultvalue.org (Postfix) with ESMTPSA id B552490D2B; Sat, 25 Jan 2014 13:32:42 -0600 (CST) Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id 5482F14E14B; Sat, 25 Jan 2014 13:32:42 -0600 (CST) From: Rob Browning To: Austin Clements Subject: Re: [PATCH 2/5] test: fix insert folder: searches References: <7eb4b4ee3345e7b166f9dd142435da32ffeffc86.1389304779.git.jani@nikula.org> <87txctm5zo.fsf@awakening.csail.mit.edu> Date: Sat, 25 Jan 2014 13:32:42 -0600 In-Reply-To: <87txctm5zo.fsf@awakening.csail.mit.edu> (Austin Clements's message of "Fri, 24 Jan 2014 16:20:43 -0500") Message-ID: <87y523rh5x.fsf@trouble.defaultvalue.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) 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: Sat, 25 Jan 2014 19:41:53 -0000 Austin Clements writes: > This is the other reason I disagree with including cur/new. If we strip > it, people's existing folder: searches will mostly continue to work. If > we include it, such saved searches, scripted searches, and post-new > hooks are guaranteed to break. What about Maildir++'s ".folder" vs an mh (or other) "folder"? And it might be deemed unimportant, but always unifying cur/new will make it impossible for someone not using Maildir to independently refer to legitimate directories named cur and new. If it were feasible to rewrite queries, I'd be tempted to consider adding a fully literal path:, and then building a "more magic" maildir: or folder: on top, via rewriting. Regardless, I suspect that in the long run it might make sense to support literal searches somehowm, in addition to any more "friendly" option (that perhaps guesses about the mailstore type, etc.). One possibility might be to change the current literal folder: proposal to present itself as path: (leaving folder: alone). Then any rework of folder: (as the friendlier term) could be considered independently. But I don't feel very strongly about any of this. I'll be happy with any reasonable way to specify specific "folders" in a Maildir++ tree (with or without cur/new unification, etc.). Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4