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 44A12431FBD for ; Fri, 31 Jan 2014 11:19:54 -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 l4YU-mL87D-A for ; Fri, 31 Jan 2014 11:19:49 -0800 (PST) Received: from defaultvalue.org (defaultvalue.org [70.85.129.156]) by olra.theworths.org (Postfix) with ESMTP id 52FF8431FB6 for ; Fri, 31 Jan 2014 11:19:49 -0800 (PST) Received: from trouble.defaultvalue.org (localhost [127.0.0.1]) (Authenticated sender: rlb@defaultvalue.org) by defaultvalue.org (Postfix) with ESMTPSA id D62DC90D2B; Fri, 31 Jan 2014 13:19:47 -0600 (CST) Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id 25B3514E14E; Fri, 31 Jan 2014 13:19:47 -0600 (CST) From: Rob Browning To: Austin Clements Subject: Re: [PATCH 0/5] lib: make folder: prefix literal References: <87y525m649.fsf@awakening.csail.mit.edu> <87r47wfltb.fsf@nikula.org> <87iot8f4vg.fsf@nikula.org> <20140130220234.GI4375@mit.edu> Date: Fri, 31 Jan 2014 13:19:47 -0600 In-Reply-To: <20140130220234.GI4375@mit.edu> (Austin Clements's message of "Thu, 30 Jan 2014 17:02:34 -0500") Message-ID: <871tzovu0c.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: Fri, 31 Jan 2014 19:19:54 -0000 Austin Clements writes: > folder: could work the way I suggested (simply the path to the file, > with {cur,new} stripped off). Hmm, so would notmuch try to guess whether or not it's dealing with a maildir++ tree, and if so convert folder:foo to a search of .foo, and/or folder:foo/bar to .foo.bar? Or would the user just need to know to say folder:.foo and folder:.foo.bar? And if we're only planning special treatment for for maildir-like stores, then I wonder if the term should just be maildir:? Though folder: would make more sense if the long-term goal was to have a "DTRT" term. But in that case, I wonder if it might eventually be expected to support mixed trees, i.e. say a tree containing maildir++ and mh subdirs, and if so, how that should be handled. > many shells support "**" for recursive path matching and people are > already quite familiar with glob patterns for paths, so why not simply > adopt this? rsync too. -- 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