96/4c824469b2c69de491756141bb1480c6bae063

   1 Return-Path: <cworth@cworth.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 95FCE4196F0\r
   6         for <notmuch@notmuchmail.org>; Thu,  8 Apr 2010 14:28:28 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -2.89\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
  13         autolearn=ham\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id HBLjLF7FhhlJ; Thu,  8 Apr 2010 14:28:27 -0700 (PDT)\r
  17 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 7B441431FC1;\r
  19         Thu,  8 Apr 2010 14:28:27 -0700 (PDT)\r
  20 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  21         id 0586C558038; Thu,  8 Apr 2010 14:28:27 -0700 (PDT)\r
  22 From: Carl Worth <cworth@cworth.org>\r
  23 To: Dirk Hohndel <hohndel@infradead.org>, Jameson Rollins\r
  24         <jrollins@finestructure.net>, notmuch@notmuchmail.org\r
  25 Subject: Re: Plans for the 0.2 release (this week)\r
  26 In-Reply-To: <m3tyrmgfdk.fsf@x200.gr8dns.org>\r
  27 References: <8739z6rjxf.fsf@yoom.home.cworth.org>\r
  28         <87tyrmavoc.fsf@servo.finestructure.net>\r
  29         <m3tyrmgfdk.fsf@x200.gr8dns.org>\r
  30 Date: Thu, 08 Apr 2010 14:28:20 -0700\r
  31 Message-ID: <87ochtd47f.fsf@yoom.home.cworth.org>\r
  32 MIME-Version: 1.0\r
  33 Content-Type: multipart/signed; boundary="=-=-=";\r
  34         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  35 X-BeenThere: notmuch@notmuchmail.org\r
  36 X-Mailman-Version: 2.1.13\r
  37 Precedence: list\r
  38 List-Id: "Use and development of the notmuch mail system."\r
  39         <notmuch.notmuchmail.org>\r
  40 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  41         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  42 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  43 List-Post: <mailto:notmuch@notmuchmail.org>\r
  44 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  45 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  46         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  47 X-List-Received-Date: Thu, 08 Apr 2010 21:28:28 -0000\r
  48 \r
  49 --=-=-=\r
  50 Content-Transfer-Encoding: quoted-printable\r
  51 \r
  52 On Thu, 08 Apr 2010 07:58:47 -0700, Dirk Hohndel <hohndel@infradead.org> wr=\r
  53 ote:\r
  54 > On Thu, 08 Apr 2010 10:03:15 -0400, Jameson Rollins <jrollins@finestructu=\r
  55 re.net> wrote:\r
  56 > > Also, fwiw, the folder: indexing is probably the new feature that I'm\r
  57 > > most eagerly awaiting.  I've got all these ideas for ways to handle sent\r
  58 > > mail and drafts if we can get this working.\r
  59 >=20\r
  60 > Maybe I am missing some context here - what exactly does 'indexing' mean\r
  61 > here?\r
  62 \r
  63 Indexing here means shoving information into the database to make it\r
  64 searchable.\r
  65 \r
  66 I was a bit vague in my description of the features I want to enable\r
  67 here. So let me start making it a bit more clear. I'd like to add\r
  68 support for the following:\r
  69 \r
  70   1. A "folder:" prefix in the search syntax that will match components\r
  71      of the directory in which mail files are stored. So, if you've got\r
  72      mail filed into directories, (from using a folder-based email\r
  73      program, or from doing an imap sync from gmail that turns tags into\r
  74      directories), then you could search for things like "folder:spam",\r
  75      "folder:important", "folder:arbitrary/subset/of/some/path", etc.\r
  76 \r
  77   2. A "list:" prefix to match content from headers that identify\r
  78      mailing list. My perception is that there are likely a handful of\r
  79      different headers that have been used, and they should all be\r
  80      indexed so that "list:" will search any of them.\r
  81 \r
  82   3. Some prefix that can be used to match typical headers added by\r
  83      spam-filtering software, (maybe this would be a general\r
  84      prefix---see below).\r
  85 \r
  86 I think the above are probably the three I can think of that pretty much\r
  87 everybody has asked for, so that should be indexed by default.\r
  88 \r
  89 Beyond that, I'd like to be able to provide support for arbitrary\r
  90 headers in the email. I had envisioned allowing the user to configure\r
  91 specific headers to index. Alternately, I had imagined having a\r
  92 blacklist of "uninteresting" headers and indexing everything\r
  93 else. (Though, now Dirk is very interested in Received and its perhaps\r
  94 provides the most content of any of the headers I originally thought\r
  95 would be "uninteresting".)\r
  96 \r
  97 One experiment I should do is to measure how much my database would grow\r
  98 if I were to index all of the header content. I don't really know what\r
  99 kind of a percentage we're talking about.\r
 100 \r
 101 Finally, we'd need a syntax for searching all of these headers. Rather\r
 102 than trying to map each header name to a custom prefix, I think what\r
 103 might be best would be a general thing that could look like:\r
 104 \r
 105         header:"X-Spam-Flag: YES"\r
 106 \r
 107 We don't currently have the ability to tie a search to the beginning of\r
 108 a line, but it occurs to me that we could do something fancy like index\r
 109 each header with a specific term to indicate line beginnings. Then, with\r
 110 a custom query parser we could use the common symbol of '^' to map to\r
 111 that. That would enable something like:\r
 112 \r
 113         header:"^X-Spam-Flag: YES"\r
 114 \r
 115 That's a lot of work though, (and perhaps not as important as it's\r
 116 probably uncommon for a header name to appear within the value of some\r
 117 other header).\r
 118 \r
 119 > Hmm - haven't even thought about drafts, yet. How would the UI deal with\r
 120 > those?=20\r
 121 \r
 122 I would imagine another "folder" alongside the others that would list\r
 123 all drafts, and selecting any such message would bring up the message in\r
 124 a mode to edit it.\r
 125 \r
 126 Sup also displayed draft messages in their proper location in the\r
 127 threads containing the message being replied to, (and highlighted such\r
 128 threads in the search view).\r
 129 \r
 130 All of that sounds quite easy to do by simply saving the draft within\r
 131 the mailstore and giving it a "draft" tag.\r
 132 \r
 133 Finally, many mail interfaces prompt from the "compose new message"\r
 134 command whether an existing draft should be continued. That's useful to\r
 135 help the user avoid forgetting to complete and send a draft that was\r
 136 forgotten.\r
 137 \r
 138 =2DCarl\r
 139 \r
 140 \r
 141 \r
 142 --=-=-=\r
 143 Content-Type: application/pgp-signature\r
 144 \r
 145 -----BEGIN PGP SIGNATURE-----\r
 146 Version: GnuPG v1.4.10 (GNU/Linux)\r
 147 \r
 148 iD8DBQFLvkp06JDdNq8qSWgRAjhqAJ9kFvvV47mxEQaGkjO5R52Xhwy/1gCgpVOy\r
 149 O3KVd9EAIqBU7L1TEsJgvt4=\r
 150 =B6vt\r
 151 -----END PGP SIGNATURE-----\r
 152 --=-=-=--\r