Return-Path: <jani@nikula.org>
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 21CC7431FBC
	for <notmuch@notmuchmail.org>; 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 <notmuch@notmuchmail.org>;
	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 <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 01:33:09 -0800 (PST)
Received: by mail-ea0-f177.google.com with SMTP id n15so1400491ead.36
	for <notmuch@notmuchmail.org>; 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 <multiple recipients>
	(version=TLSv1.2 cipher=RC4-SHA bits=128/128);
	Sat, 25 Jan 2014 01:33:06 -0800 (PST)
From: Jani Nikula <jani@nikula.org>
To: Austin Clements <aclements@csail.mit.edu>, notmuch@notmuchmail.org
Subject: Re: [PATCH 0/5] lib: make folder: prefix literal
In-Reply-To: <87y525m649.fsf@awakening.csail.mit.edu>
References: <cover.1389304779.git.jani@nikula.org>
	<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."
	<notmuch.notmuchmail.org>
List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
List-Archive: <http://notmuchmail.org/pipermail/notmuch>
List-Post: <mailto:notmuch@notmuchmail.org>
List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jan 2014 09:33:46 -0000

On Fri, 24 Jan 2014, Austin Clements <aclements@csail.mit.edu> wrote:
> On Thu, 09 Jan 2014, Jani Nikula <jani@nikula.org> 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