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 21CC7431FBC for ; Sat, 25 Jan 2014 01:33:46 -0800 (PST) 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 cnUfVm1sY0SL for ; Sat, 25 Jan 2014 01:33:10 -0800 (PST) Received: from mail-ea0-f177.google.com (mail-ea0-f177.google.com [209.85.215.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id CBDF2431FB6 for ; Sat, 25 Jan 2014 01:33:09 -0800 (PST) Received: by mail-ea0-f177.google.com with SMTP id n15so1400491ead.36 for ; Sat, 25 Jan 2014 01:33:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-type; bh=Np2l6yNoM8oQEqs4pplOyelw5Tjd2QXf/8RAqusM2qc=; b=QvyoQO4JBZqa1jgQjufs9T87r5to6MTwO5WWVfMHf0X4iGuTKXdaO4foNb94CsVs86 tNjX7V7rgm6lgNFcR5ENsIgz5eMZmGfqhB8mWcV7lHeR+n0WGxp4URBR/+obld7OowN8 l1MQeoGqNkWCgDo1gMztCmOXO/Wl+oMFQ1Kl6R89IR3cTf4G5X4Ho9suo5h8/P4X/MPE /R07FQ1scSLFLV0HjpXuTpnYHPlWy5CLbVgEoaI2drdkIDj710kyUtYSRLRqzfylJZ6E iu/Hnl2rlIpO/8jYIUD7EetpM/+9c3i6H+UgfgyT1rxsCCEyTSK/fbKXPUsEzOkaPLs+ QvzA== X-Gm-Message-State: ALoCoQlHqX1YylKnv2AXSb1Jrpi7L6Q2Huwo1cCdJnfGxno37EdHa04oag6TQaDv8XrrQcn10rH0 X-Received: by 10.15.41.7 with SMTP id r7mr389487eev.98.1390642387205; Sat, 25 Jan 2014 01:33:07 -0800 (PST) Received: from localhost (dsl-hkibrasgw2-58c36f-91.dhcp.inet.fi. [88.195.111.91]) by mx.google.com with ESMTPSA id 4sm13810215eed.14.2014.01.25.01.33.05 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 25 Jan 2014 01:33:06 -0800 (PST) From: Jani Nikula To: Austin Clements , notmuch@notmuchmail.org Subject: Re: [PATCH 0/5] lib: make folder: prefix literal In-Reply-To: <87y525m649.fsf@awakening.csail.mit.edu> References: <87y525m649.fsf@awakening.csail.mit.edu> User-Agent: Notmuch/0.17+44~ge3b4cd9 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Sat, 25 Jan 2014 11:33:04 +0200 Message-ID: <87r47wfltb.fsf@nikula.org> MIME-Version: 1.0 Content-Type: text/plain 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 09:33:46 -0000 On Fri, 24 Jan 2014, Austin Clements wrote: > On Thu, 09 Jan 2014, Jani Nikula wrote: >> Hi all, this series makes the folder: search prefix literal, or switches >> it from a probabilistic prefix to a boolean prefix. With this, you have >> to give the path from the maildir root to the folder you want in full, >> including the maildir cur/new component, if any. Examples: > > I strongly disagree with requiring the cur/new component. The cur/new > directory is an internal implementation detail of Maildir (and a rather > broken one at that) and no more a part of the "folder" of a piece of > mail than its final file name component. It's also the less obvious > user interface; if we require the cur/new component, we *will* get > people asking why their folder searches aren't working, but if we strip > the cur/new component, nobody will be surprised. > > I think the question is not whether we should strip cur/new, but when. > We've already defined a "_filename_is_in_maildir" test in > lib/message.cc, which we depend on for flag sync. It's simple, but I > think this would be the right thing to use for consistency. I'd like to discuss some of the reasons I chose to include the cur/new components. Admittedly, none of them are very strong on their own, but all of them together tilted my opinion towards requiring them. The way I see it, notmuch supports maildir, but does not require it. In many ways the messages are just files somewhere in the directory hierarchy. There are only a few cases where it matters that there are cur/new/tmp directories within a directory. If you strip cur and new, it becomes impossible to distinguish between files in foo, foo/cur, and foo/new - and one of the reasons for changing folder: in the first place is to be able to better distinguish between folders. Apparently mutt presents the difference between messages in new and cur to its users (so I've been told; I've never really used mutt), and our integration with mutt lacks that distinction. We could fix that by requiring the cur/new components in folder: searches. Speaking of consistency, compare _filename_is_in_maildir() with _entries_resemble_maildir() in notmuch-new.c. What should the indexed folder: prefix be if there is not all of cur, new, and tmp? We will actually index files in tmp if cur or new is not present! What if the missing sibling directories are added (or existing ones removed) later? Where's the consistency compared to new.ignore config, which also matches the cur/new components if so desired? Or consistency with notmuch search --output=files? My conclusion was that requiring *all* filesystem folder components as-is is consistent, most versatile, agnostic to Maildir or Maildir++ implementation details wrt directory naming or hierarchy, without difficult corner cases, simplest to implement, and unsurprising (once you understand the cur/new distinction). For *me* this is the more obvious user interface. And hey, I'm a user too. Perhaps we need to have two prefixes, one of which is the literal filesystem folder and another which hides the implementation details, like I mentioned in my mail to Peter [1]. But consider this: my proposed implementation does cover *all* use cases. BR, Jani. [1] id:8761ppurfz.fsf@nikula.org