5f/ba04f47d1835c48b5600b7e76210650c1000dd

   1 Return-Path: <jrollins@finestructure.net>\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 94EDF431FBC\r
   6         for <notmuch@notmuchmail.org>; Mon,  1 Feb 2010 10:14:33 -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: -1.16\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[AWL=-1.161,\r
  12         BAYES_50=0.001] autolearn=ham\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 LsoPSWQM5KZ7 for <notmuch@notmuchmail.org>;\r
  16         Mon,  1 Feb 2010 10:14:32 -0800 (PST)\r
  17 Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 816EF431FAE\r
  19         for <notmuch@notmuchmail.org>; Mon,  1 Feb 2010 10:14:32 -0800 (PST)\r
  20 Received: from servo.finestructure.net (geco.phys.columbia.edu\r
  21         [128.59.170.159])\r
  22         (user=jgr2110 author=jrollins@finestructure.net mech=PLAIN bits=0)\r
  23         by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o11IENYF001320\r
  24         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT)\r
  25         for <notmuch@notmuchmail.org>; Mon, 1 Feb 2010 13:14:24 -0500 (EST)\r
  26 Received: from jrollins by servo.finestructure.net with local (Exim 4.71)\r
  27         (envelope-from <jrollins@finestructure.net>) id 1Nc0n1-0005AW-NH\r
  28         for notmuch@notmuchmail.org; Mon, 01 Feb 2010 13:14:23 -0500\r
  29 From: Jameson Rollins <jrollins@finestructure.net>\r
  30 To: Notmuch Mail <notmuch@notmuchmail.org>\r
  31 Date: Mon, 01 Feb 2010 13:14:20 -0500\r
  32 Message-ID: <87eil4ygar.fsf@servo.finestructure.net>\r
  33 MIME-Version: 1.0\r
  34 Content-Type: multipart/signed; boundary="=-=-=";\r
  35         micalg=pgp-sha256; protocol="application/pgp-signature"\r
  36 X-No-Spam-Score: Local\r
  37 X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7\r
  38 Subject: [notmuch] Request for high-priority improvements to notmuch\r
  39 X-BeenThere: notmuch@notmuchmail.org\r
  40 X-Mailman-Version: 2.1.13\r
  41 Precedence: list\r
  42 List-Id: "Use and development of the notmuch mail system."\r
  43         <notmuch.notmuchmail.org>\r
  44 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  45         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  46 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  47 List-Post: <mailto:notmuch@notmuchmail.org>\r
  48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  49 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  50         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  51 X-List-Received-Date: Mon, 01 Feb 2010 18:14:33 -0000\r
  52 \r
  53 --=-=-=\r
  54 \r
  55 Hello Carl et. al.\r
  56 \r
  57 I know you're trying to work through a boat load of backlog patches, but\r
  58 after using notmuch for a couple weeks now, I would like to highlight\r
  59 what I think are the two most important things that need to be be\r
  60 implemented in the notmuch CLI and why.\r
  61 \r
  62 Ability to apply tags based on folder paths in "notmuch new"\r
  63 ------------------------------------------------------------\r
  64 Notmuch needs to be able to be configured to tag messages differently if\r
  65 they appear in different folders (mentioned previously in\r
  66 id:87tyu9dfhs.fsf@servo.finestructure.net).  For instance, for\r
  67 "inbox"/"sent"/"drafts"/"archive" maildir subdirectories of your primary\r
  68 mail directory "/home/user/mail", a notmuch config could look like this:\r
  69 \r
  70    [database]\r
  71    path=/home/user/mail\r
  72 \r
  73    [tags]\r
  74    inbox = +inbox,+unread\r
  75    sent = +sent\r
  76    drafts = +draft\r
  77    archive = -inbox\r
  78 \r
  79 In other words, a user could specify that new messages to the maildir\r
  80 "/home/user/mail/sent" would be tagged *only* with the "sent" tag.\r
  81 \r
  82 This is very important for being able to handle different kinds of new\r
  83 messages differently, which is very important for being able to have\r
  84 notmuch handle things that it is currently unable to handle.  If this is\r
  85 *not* implemented, then there is no way to distinguish different kinds\r
  86 of new mail in notmuch, which severely restricts subtle handling of\r
  87 different mail situations.\r
  88 \r
  89 For instance, this feature would deal with the following problems:\r
  90 \r
  91 * Notmuch currently does not handle sent mail.  If sent messages are to\r
  92 be indexed, then they need to be delivered or fcc'd to a maildir which\r
  93 is indexed by notmuch.  But this means they currently always show up as\r
  94 "inbox"/"unread", which means they always appear in the inbox.  Folder\r
  95 based tagging would allow sent mail to instead be delivered or fcc'd to\r
  96 a sent mail or archive folder that would not get the "inbox"/"unread"\r
  97 tags.\r
  98 \r
  99 * Notmuch currently does not handle draft messages.  If this folder\r
 100 tagging scheme is available, draft messages could be stored in an\r
 101 indexed directory, which would allow viewing of draft messages\r
 102 (currently also not supported), and therefore building simple functions\r
 103 to resume saved drafts.\r
 104 \r
 105 I really believe this needs to be implemented in "notmuch new".  If it\r
 106 were implemented in a separate function it would require two calls to\r
 107 notmuch for every notmuch new, which would be a waste.\r
 108 \r
 109 JSON output for "notmuch search/show" with ability to filter output fields\r
 110 --------------------------------------------------------------------------\r
 111 This is very important to enable more effective, streamlined, and faster\r
 112 notmuch helper functions and scripts.  There has been a lot of\r
 113 discussion about what notmuch should or should not be handling.  No\r
 114 matter what eventually happens, it is clear that notmuch needs to make\r
 115 it as easy as possible for external applications to parse it's output.\r
 116 Clearly the best way to do that is to provide JSON output, which is a\r
 117 widely adopted standard that is well supported in any language one\r
 118 might want to use to build a notmuch wrapper.\r
 119 \r
 120 If notmuch could also be told to output only certain desired fields,\r
 121 then parsing by clients would be made significantly more efficient.  Not\r
 122 to mention the notmuch UI itself could be streamlined as the "search"\r
 123 and "show" functions could be combined into a single subcommand:\r
 124 \r
 125 "search" --> "search --output=thread_id,date,number,author,subject,tags"\r
 126  "show"  --> "search --output=message_id,tags,path,header,body,attachments"\r
 127 \r
 128 This would all make things *much* easier for clients.  For instance,\r
 129 here are just a couple of things that could handled in wrapper scripts\r
 130 that would be greatly facilitated by this proposal (including proposed\r
 131 notmuch search filtered output commands):\r
 132 \r
 133 * Proper maildir sync ("search --output=message_id,tags,path" ...)\r
 134 \r
 135 * Purging "delete" tagged messages ("search --output=path" tags:delete)\r
 136 \r
 137 * Moving/archiving messages based on search results ("search --output=path" ...)\r
 138 \r
 139 * New client viewers\r
 140 \r
 141 I believe there is already a patch in the queue to move to JSON output,\r
 142 so hopefully this can be implemented without much further work.\r
 143 \r
 144 --------------------------------------------------\r
 145 \r
 146 I really think these enhancements are very important, and notmuch should\r
 147 be aiming to implement them soon.  They would greatly extend the\r
 148 capabilities of notmuch, without restricting it's usage at all.  They\r
 149 would blow open the doors for making notmuch helper applications, which\r
 150 would essentially eliminate further discussion on what notmuch should\r
 151 be handling natively or not.  A lot of the current shortcomings of\r
 152 notmuch could be easily dealt with if these enhancements are\r
 153 implemented.\r
 154 \r
 155 Thanks so much for the time, and I look forward to any discussion on\r
 156 these ideas, and to seeing them in near-future releases.\r
 157 \r
 158 jamie.\r
 159 \r
 160 --=-=-=\r
 161 Content-Type: application/pgp-signature\r
 162 \r
 163 -----BEGIN PGP SIGNATURE-----\r
 164 Version: GnuPG v1.4.10 (GNU/Linux)\r
 165 \r
 166 iQIcBAEBCAAGBQJLZxn8AAoJEO00zqvie6q8zXAP/34SRuaT6ckuD/ogUIvft1O6\r
 167 h61ill+k2gLIQH4uUzaWNPmFzKKE9add0r0GoUZLGSX6B6N6eWbdrUdECBAb10lN\r
 168 GX08l/56yxC51nhotd57V6NNKOLjN3qlnUJ5LkWZrOjWPbB1ftHcRVQF5LsSmEP6\r
 169 mRhlI8vUOG9bCuc3Mmf35LY3appM/3XyUTnoiNi/Geppq/yKY6FWTCrhtgga9lVj\r
 170 WmX/ai+3T771O8fdd8eM7JDrF4sJKADRkvmO/L6mlxdp4tN7J7IU+7IHFjah12ss\r
 171 61wecqSTKw/4ro3dpJuZhu44BAdVI0jC8zSVIQ6UQ6E9p0QQpzNrrv6uxug7LPRd\r
 172 UsMpYlpLbXbYVVbRrgb+WVcE5QhMvioBrIeoLHOjNztgaIOtEUKBdsFzFsAp/qxC\r
 173 iH1RNa9WYDQror+FuknmHwNdxu0OTRg4HmpmSIgTgOlmU+9mwhvfJyO0d+ugjp1m\r
 174 bNdhAdK4m3KHX5h+yj9KL4UVV9qD0qtKVKiSA6Y5XU/L/hm1ygkQ6znHGtKGry2u\r
 175 7RJalNj9pCg8+FY3xkDCg5yVNMgnDJb55rPxoMZw9NXofPVUYOSfNTvAt4+9XuFT\r
 176 RSdO40VyCNt91LUoY2J6i5sXtk79rvLbfNkQ4nog9V97jDYiZS4KjZ6NfP7+Yz7t\r
 177 Sy9N2aqlj4Bto/E9OmmE\r
 178 =Io6d\r
 179 -----END PGP SIGNATURE-----\r
 180 --=-=-=--\r