27/45fb5be874fe34415c8aef9ad986ff1532ae76

   1 Return-Path: <jani@nikula.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 21CC7431FBC\r
   6         for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 01:33:46 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id cnUfVm1sY0SL for <notmuch@notmuchmail.org>;\r
  16         Sat, 25 Jan 2014 01:33:10 -0800 (PST)\r
  17 Received: from mail-ea0-f177.google.com (mail-ea0-f177.google.com\r
  18         [209.85.215.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id CBDF2431FB6\r
  21         for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 01:33:09 -0800 (PST)\r
  22 Received: by mail-ea0-f177.google.com with SMTP id n15so1400491ead.36\r
  23         for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 01:33:07 -0800 (PST)\r
  24 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
  25         d=1e100.net; s=20130820;\r
  26         h=x-gm-message-state:from:to:subject:in-reply-to:references\r
  27         :user-agent:date:message-id:mime-version:content-type;\r
  28         bh=Np2l6yNoM8oQEqs4pplOyelw5Tjd2QXf/8RAqusM2qc=;\r
  29         b=QvyoQO4JBZqa1jgQjufs9T87r5to6MTwO5WWVfMHf0X4iGuTKXdaO4foNb94CsVs86\r
  30         tNjX7V7rgm6lgNFcR5ENsIgz5eMZmGfqhB8mWcV7lHeR+n0WGxp4URBR/+obld7OowN8\r
  31         l1MQeoGqNkWCgDo1gMztCmOXO/Wl+oMFQ1Kl6R89IR3cTf4G5X4Ho9suo5h8/P4X/MPE\r
  32         /R07FQ1scSLFLV0HjpXuTpnYHPlWy5CLbVgEoaI2drdkIDj710kyUtYSRLRqzfylJZ6E\r
  33         iu/Hnl2rlIpO/8jYIUD7EetpM/+9c3i6H+UgfgyT1rxsCCEyTSK/fbKXPUsEzOkaPLs+\r
  34         QvzA==\r
  35 X-Gm-Message-State:\r
  36  ALoCoQlHqX1YylKnv2AXSb1Jrpi7L6Q2Huwo1cCdJnfGxno37EdHa04oag6TQaDv8XrrQcn10rH0\r
  37 X-Received: by 10.15.41.7 with SMTP id r7mr389487eev.98.1390642387205;\r
  38         Sat, 25 Jan 2014 01:33:07 -0800 (PST)\r
  39 Received: from localhost (dsl-hkibrasgw2-58c36f-91.dhcp.inet.fi.\r
  40         [88.195.111.91])\r
  41         by mx.google.com with ESMTPSA id 4sm13810215eed.14.2014.01.25.01.33.05\r
  42         for <multiple recipients>\r
  43         (version=TLSv1.2 cipher=RC4-SHA bits=128/128);\r
  44         Sat, 25 Jan 2014 01:33:06 -0800 (PST)\r
  45 From: Jani Nikula <jani@nikula.org>\r
  46 To: Austin Clements <aclements@csail.mit.edu>, notmuch@notmuchmail.org\r
  47 Subject: Re: [PATCH 0/5] lib: make folder: prefix literal\r
  48 In-Reply-To: <87y525m649.fsf@awakening.csail.mit.edu>\r
  49 References: <cover.1389304779.git.jani@nikula.org>\r
  50         <87y525m649.fsf@awakening.csail.mit.edu>\r
  51 User-Agent: Notmuch/0.17+44~ge3b4cd9 (http://notmuchmail.org) Emacs/24.3.1\r
  52         (x86_64-pc-linux-gnu)\r
  53 Date: Sat, 25 Jan 2014 11:33:04 +0200\r
  54 Message-ID: <87r47wfltb.fsf@nikula.org>\r
  55 MIME-Version: 1.0\r
  56 Content-Type: text/plain\r
  57 X-BeenThere: notmuch@notmuchmail.org\r
  58 X-Mailman-Version: 2.1.13\r
  59 Precedence: list\r
  60 List-Id: "Use and development of the notmuch mail system."\r
  61         <notmuch.notmuchmail.org>\r
  62 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  63         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  64 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  65 List-Post: <mailto:notmuch@notmuchmail.org>\r
  66 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  67 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  68         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  69 X-List-Received-Date: Sat, 25 Jan 2014 09:33:46 -0000\r
  70 \r
  71 On Fri, 24 Jan 2014, Austin Clements <aclements@csail.mit.edu> wrote:\r
  72 > On Thu, 09 Jan 2014, Jani Nikula <jani@nikula.org> wrote:\r
  73 >> Hi all, this series makes the folder: search prefix literal, or switches\r
  74 >> it from a probabilistic prefix to a boolean prefix. With this, you have\r
  75 >> to give the path from the maildir root to the folder you want in full,\r
  76 >> including the maildir cur/new component, if any. Examples:\r
  77 >\r
  78 > I strongly disagree with requiring the cur/new component.  The cur/new\r
  79 > directory is an internal implementation detail of Maildir (and a rather\r
  80 > broken one at that) and no more a part of the "folder" of a piece of\r
  81 > mail than its final file name component.  It's also the less obvious\r
  82 > user interface; if we require the cur/new component, we *will* get\r
  83 > people asking why their folder searches aren't working, but if we strip\r
  84 > the cur/new component, nobody will be surprised.\r
  85 >\r
  86 > I think the question is not whether we should strip cur/new, but when.\r
  87 > We've already defined a "_filename_is_in_maildir" test in\r
  88 > lib/message.cc, which we depend on for flag sync.  It's simple, but I\r
  89 > think this would be the right thing to use for consistency.\r
  90 \r
  91 I'd like to discuss some of the reasons I chose to include the cur/new\r
  92 components. Admittedly, none of them are very strong on their own, but\r
  93 all of them together tilted my opinion towards requiring them.\r
  94 \r
  95 The way I see it, notmuch supports maildir, but does not require it. In\r
  96 many ways the messages are just files somewhere in the directory\r
  97 hierarchy. There are only a few cases where it matters that there are\r
  98 cur/new/tmp directories within a directory.\r
  99 \r
 100 If you strip cur and new, it becomes impossible to distinguish between\r
 101 files in foo, foo/cur, and foo/new - and one of the reasons for changing\r
 102 folder: in the first place is to be able to better distinguish between\r
 103 folders.\r
 104 \r
 105 Apparently mutt presents the difference between messages in new and cur\r
 106 to its users (so I've been told; I've never really used mutt), and our\r
 107 integration with mutt lacks that distinction. We could fix that by\r
 108 requiring the cur/new components in folder: searches.\r
 109 \r
 110 Speaking of consistency, compare _filename_is_in_maildir() with\r
 111 _entries_resemble_maildir() in notmuch-new.c. What should the indexed\r
 112 folder: prefix be if there is not all of cur, new, and tmp? We will\r
 113 actually index files in tmp if cur or new is not present! What if the\r
 114 missing sibling directories are added (or existing ones removed) later?\r
 115 Where's the consistency compared to new.ignore config, which also\r
 116 matches the cur/new components if so desired? Or consistency with\r
 117 notmuch search --output=files?\r
 118 \r
 119 My conclusion was that requiring *all* filesystem folder components\r
 120 as-is is consistent, most versatile, agnostic to Maildir or Maildir++\r
 121 implementation details wrt directory naming or hierarchy, without\r
 122 difficult corner cases, simplest to implement, and unsurprising (once\r
 123 you understand the cur/new distinction).\r
 124 \r
 125 For *me* this is the more obvious user interface. And hey, I'm a user\r
 126 too.\r
 127 \r
 128 Perhaps we need to have two prefixes, one of which is the literal\r
 129 filesystem folder and another which hides the implementation details,\r
 130 like I mentioned in my mail to Peter [1]. But consider this: my proposed\r
 131 implementation does cover *all* use cases.\r
 132 \r
 133 \r
 134 BR,\r
 135 Jani.\r
 136 \r
 137 \r
 138 [1] id:8761ppurfz.fsf@nikula.org\r