98/d0cd6de39e759893c8395cac0936156b3bf95e

   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 19567431FBF\r
   6         for <notmuch@notmuchmail.org>; Sat,  1 Feb 2014 06:54:29 -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 Gkz3wK1sj3ui for <notmuch@notmuchmail.org>;\r
  16         Sat,  1 Feb 2014 06:54:25 -0800 (PST)\r
  17 Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com\r
  18  [74.125.83.46])        (using TLSv1 with cipher RC4-SHA (128/128 bits))        (No client\r
  19  certificate requested) by olra.theworths.org (Postfix) with ESMTPS id\r
  20  14F28431FBD    for <notmuch@notmuchmail.org>; Sat,  1 Feb 2014 06:54:24 -0800\r
  21  (PST)\r
  22 Received: by mail-ee0-f46.google.com with SMTP id c13so2754427eek.5\r
  23         for <notmuch@notmuchmail.org>; Sat, 01 Feb 2014 06:54:23 -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:cc:subject:in-reply-to:references\r
  27         :user-agent:date:message-id:mime-version:content-type;\r
  28         bh=hOpNcrd+p+Y+5ZMi3qG1FeBvJQSXKRiclwMdusszEH0=;\r
  29         b=QL5jkEp0lcNBTGoSw06qsX/Ws1UdfR0SsHCgMlAqmI/h0S2nnIv6JOLIvXoWZJlia2\r
  30         zDIPrjvlPFid9GUzrpoUfMOV/lzHVnXvZ7uFlxD5WZgtVu2/Z8iUOY/G8fJ9dBz9diAB\r
  31         NXPtWhhYkF7lS7RtweYm8MdGiu3aAvvudsEgkpiCqCIO7O/iDeA+0Ln3ICEtbDruidGN\r
  32         A2zk/pu3dqtey3Gn2VN6HIszVU1twBubHRrOGJ7OQgYVrjaA1o7Eq4bzhQ4vMkMeoyS7\r
  33         wFtkhUg6UjGVxjYRkN1wdCXcNBqFlDzPhddky5kp0nRyVRYmvO3b16YeOyRNQT7fAJIx\r
  34         5Nbg==\r
  35 X-Gm-Message-State:\r
  36  ALoCoQn07yRBTY5bTI1U0uSJUUzobMV7kaa45tmCNKaGrrKPbcl5NrsBIwedA19yysgNj8T99s93\r
  37 X-Received: by 10.14.2.193 with SMTP id 41mr21090234eef.55.1391266462369;\r
  38         Sat, 01 Feb 2014 06:54:22 -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 g1sm50286382eet.6.2014.02.01.06.54.20\r
  42         for <multiple recipients>\r
  43         (version=TLSv1.2 cipher=RC4-SHA bits=128/128);\r
  44         Sat, 01 Feb 2014 06:54:21 -0800 (PST)\r
  45 From: Jani Nikula <jani@nikula.org>\r
  46 To: Austin Clements <amdragon@MIT.EDU>\r
  47 Subject: Re: [PATCH 0/5] lib: make folder: prefix literal\r
  48 In-Reply-To: <20140130220234.GI4375@mit.edu>\r
  49 References: <cover.1389304779.git.jani@nikula.org>\r
  50         <87y525m649.fsf@awakening.csail.mit.edu>\r
  51         <87r47wfltb.fsf@nikula.org> <87iot8f4vg.fsf@nikula.org>\r
  52         <20140130220234.GI4375@mit.edu>\r
  53 User-Agent: Notmuch/0.17+44~ge3b4cd9 (http://notmuchmail.org) Emacs/24.3.1\r
  54         (x86_64-pc-linux-gnu)\r
  55 Date: Sat, 01 Feb 2014 16:54:19 +0200\r
  56 Message-ID: <87fvo2yjc4.fsf@nikula.org>\r
  57 MIME-Version: 1.0\r
  58 Content-Type: text/plain\r
  59 Cc: notmuch@notmuchmail.org\r
  60 X-BeenThere: notmuch@notmuchmail.org\r
  61 X-Mailman-Version: 2.1.13\r
  62 Precedence: list\r
  63 List-Id: "Use and development of the notmuch mail system."\r
  64         <notmuch.notmuchmail.org>\r
  65 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  66         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  67 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  68 List-Post: <mailto:notmuch@notmuchmail.org>\r
  69 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  70 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  71         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  72 X-List-Received-Date: Sat, 01 Feb 2014 14:54:29 -0000\r
  73 \r
  74 On Fri, 31 Jan 2014, Austin Clements <amdragon@MIT.EDU> wrote:\r
  75 > What if we introduce two prefixes, say folder: and path: (maybe dir:?)\r
  76 > to address both use cases, each as naturally as possible?  Both would\r
  77 > be boolean prefixes because of the limitations of probabilistic\r
  78 > prefixes, but we could take advantage of Jani's idea of generating\r
  79 > several boolean terms.\r
  80 \r
  81 Agreed. On to details:\r
  82 \r
  83 > folder: could work the way I suggested (simply the path to the file,\r
  84 > with {cur,new} stripped off).\r
  85 \r
  86 What if the file is not in a folder named cur/new? I suggest indexing\r
  87 the folder as-is, if only for some backwards compatibility.\r
  88 \r
  89 What if there is not all of cur/new/tmp folders? I suggest ignoring\r
  90 that, and only look at the path to the file being indexed. This is\r
  91 simplest to implement, and it does not matter if the sibling directories\r
  92 come and go, and for this reason also unsurprising.\r
  93 \r
  94 For top level cur/new, index the empty string "".\r
  95 \r
  96 > path: would support file system search\r
  97 > uses.  These seem more varied, but I think fall into exact match and\r
  98 > recursive match.  Since I don't have this use case, I can't have any\r
  99 > strong opinions about syntax, but I'll throw out an idea: many shells\r
 100 > support "**" for recursive path matching and people are already quite\r
 101 > familiar with glob patterns for paths, so why not simply adopt this?\r
 102 > In other words, when adding the path "a/b/cur/x:2," add path: terms\r
 103 > "a/b/cur" and "a/b/**" and "a/**" and "**".\r
 104 \r
 105 Since folder: would cover the cur/new cases, I suggest the non-recursive\r
 106 variant of path: prefix is the exact filesystem folder name as-is (with\r
 107 the top level being the empty string ""). I presume this is what you\r
 108 meant too.\r
 109 \r
 110 I kind of like the "/**" suffix for recursive, but there's two small\r
 111 wrinkles: 1) it needs quoting on the command line (unlike my original\r
 112 suggestion of just "/" suffix), and 2) what should the top level\r
 113 recursive search be? path:"**" or path:"/**" or path:"./**"? I guess the\r
 114 first one is most obvious?\r
 115 \r
 116 So here's what my original suggestions would become:\r
 117 \r
 118 >> Here's a thought. With boolean prefix folder:, we can devise a scheme\r
 119 >> where the folder: query defines what is to be matched.\r
 120 >> \r
 121 >> For example:\r
 122 >> \r
 123 >> folder:foo   match files in foo, foo/new, and foo/cur.\r
 124 \r
 125 -> folder:foo\r
 126 \r
 127 >> folder:foo/  match all files in all subdirectories under foo (this\r
 128 >>              would handle Tomi's use case), including foo/new and foo/cur.\r
 129 \r
 130 -> path:"foo/**"\r
 131 \r
 132 >> folder:foo/. match in foo only, and specifically not in foo/cur or foo/new.\r
 133 \r
 134 -> path:foo\r
 135 \r
 136 >> folder:foo/new  match in foo/new, and specifically not in foo/cur (this\r
 137 >>              allows distinguishing between messages in cur and new).\r
 138 \r
 139 -> path:foo/new\r
 140 \r
 141 >> folder:/     match everything.\r
 142 \r
 143 -> path:"**"\r
 144 \r
 145 >> folder:/.    match in top level maildir only.\r
 146 \r
 147 -> path:""\r
 148 \r
 149 >> folder:""    match in top level maildir, including cur/new.\r
 150 \r
 151 -> folder:""\r
 152 \r
 153 \r
 154 I'd like these details to be ironed out and agreed on before I send the\r
 155 next version.\r
 156 \r
 157 BR,\r
 158 Jani.\r
 159 \r