2f/d8d88a518ea34124d4c8ab7d107ca6770bf21d

   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 EE58E431FBC\r
   6         for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 12:50:05 -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.762\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5\r
  12         tests=[AWL=-1.763, 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 m0SsE2X1zEaW for <notmuch@notmuchmail.org>;\r
  16         Sat, 16 Jan 2010 12:50:05 -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 24EAF431FAE\r
  19         for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 12:50:05 -0800 (PST)\r
  20 Received: from servo.finestructure.net (lair.fifthhorseman.net\r
  21         [216.254.116.241])\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 o0GKnwX6024902\r
  24         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT)\r
  25         for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 15:50:03 -0500 (EST)\r
  26 Received: from jrollins by servo.finestructure.net with local (Exim 4.71)\r
  27         (envelope-from <jrollins@finestructure.net>) id 1NWFal-0006ra-V9\r
  28         for notmuch@notmuchmail.org; Sat, 16 Jan 2010 15:49:55 -0500\r
  29 Date: Sat, 16 Jan 2010 15:49:55 -0500\r
  30 From: Jameson Rollins <jrollins@finestructure.net>\r
  31 To: Notmuch Mail <notmuch@notmuchmail.org>\r
  32 Message-ID: <20100116204955.GA858@finestructure.net>\r
  33 MIME-Version: 1.0\r
  34 Content-Type: multipart/signed; micalg=pgp-sha256;\r
  35         protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb"\r
  36 Content-Disposition: inline\r
  37 User-Agent: Mutt/1.5.20 (2009-06-14)\r
  38 X-No-Spam-Score: Local\r
  39 X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7\r
  40 Subject: [notmuch] proposal for more streamlined mail flow in notmuch\r
  41 X-BeenThere: notmuch@notmuchmail.org\r
  42 X-Mailman-Version: 2.1.13\r
  43 Precedence: list\r
  44 List-Id: "Use and development of the notmuch mail system."\r
  45         <notmuch.notmuchmail.org>\r
  46 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  47         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  48 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  49 List-Post: <mailto:notmuch@notmuchmail.org>\r
  50 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  51 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  52         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  53 X-List-Received-Date: Sat, 16 Jan 2010 20:50:06 -0000\r
  54 \r
  55 \r
  56 --VS++wcV0S1rZb1Fb\r
  57 Content-Type: text/plain; charset=us-ascii\r
  58 Content-Disposition: inline\r
  59 \r
  60 I would like to put forth here a proposal for a couple of changes to\r
  61 notmuch that I believe will considerably streamline message handling\r
  62 and new message flow through notmuch.  Notmuch is still new and I\r
  63 believe it hasn't quite figured out the best way to handle message\r
  64 flow in the new mail handling paradigm that it is working.  This is a\r
  65 proposal to fix that.\r
  66 \r
  67 I believe that most people are syncing their mail from remote IMAP or\r
  68 POP servers to local maildirs (via offlineimap for instance), and that\r
  69 most people's IMAP servers have limited storage capacity.  This\r
  70 practically means that people can not keep all of their mail in a\r
  71 single directory.  However, notmuch currently basically assumes that\r
  72 this is what is happening.  In order to keep synced maildirs from\r
  73 growing out of hand, messages need to be either deleted or moved out\r
  74 of the "inbox" where they initially show up.  This is why it was so\r
  75 important for notmuch to get support for deletion/renaming/moving of\r
  76 messages.\r
  77 \r
  78 However, we still need to get notmuch to fundamentally understand this\r
  79 flow (mail comes into inbox, and is then moved elsewhere), and provide\r
  80 the functions to easily facilitate this flow for users.\r
  81 \r
  82 To this end, here is how I believe the notmuch flow should look:\r
  83 \r
  84 - New messages are delivered into a maildir "inbox".  When notmuch new\r
  85   is run, these new messages are tagged 'inbox' and 'unread'.\r
  86 \r
  87 - When a user views a message with their reader, the 'unread' tag is\r
  88   automatically removed, the maildir S flag is added and the message\r
  89   is moved from inbox/new to inbox/cur.\r
  90 \r
  91 - If the user wishes to delete a message, a 'delete' tag is added to\r
  92   the message.  If the user does a "purge", all messages tagged\r
  93   'delete' are erased from disk and/or a "delete hook" is run.\r
  94 \r
  95 - If the user wishes to archive a message the 'inbox' tag is removed\r
  96   and the messages is actually moved from the inbox maildir into an\r
  97   archive maildir and/or an "archive hook" is run.\r
  98 \r
  99 To fascilitate this, two new functions should be implemented at the\r
 100 notmuch CLI level, so that things don't get fractured by different\r
 101 mail reader implementations:\r
 102 \r
 103 notmuch purge\r
 104 \r
 105   delete all 'delete' tagged messages, and/or execute "delete hooks"\r
 106 \r
 107 notmuch archive <search-terms>\r
 108 \r
 109   remove 'inbox' flags from messages and move messages an archive\r
 110   maildir, and/or execute "archive hooks"\r
 111 \r
 112 I believe this is a simple, intuitive flow, that will be easy to\r
 113 understand and work with by pretty much all users, but is still very\r
 114 nicely extensible for advanced users.  For instance, a delete hook\r
 115 might move the message to a trash instead of deleting it outright, or\r
 116 an "archive hook" could filter archived messages into folders.  Hooks\r
 117 could also be used to do nothing to messages other than just modifying\r
 118 the tags (which would completely mimic the current notmuch behavior).\r
 119 The config file could be kept very simple (only two hooks would need\r
 120 to be defined), without having to move to some crazy script-based\r
 121 config scheme (like lua) that is overly complicated and very hard for\r
 122 new users to understand.  It would also great simplify the mail\r
 123 readers themselves (like the emacs UI), because it would greatly\r
 124 reduce the number of commands (ie. essentially just "view", "delete",\r
 125 "archive", or "search").\r
 126 \r
 127 What do folks think of this proposal?  I am convinced that this flow\r
 128 is simple, would be intuitive to new users, and extensible such that\r
 129 it could provide the functionality that anyone could desire.  I would\r
 130 be curious to hear of anyone interested in using notmuch who thinks\r
 131 they could *not* achieve the mail flow that they desire with this\r
 132 scheme.\r
 133 \r
 134 Any and all feedback on this proposal is welcome.  If people think\r
 135 this flow is a good idea, I would be psyched to start fleshing it out.\r
 136 \r
 137 jamie.\r
 138 \r
 139 --VS++wcV0S1rZb1Fb\r
 140 Content-Type: application/pgp-signature; name="signature.asc"\r
 141 Content-Description: Digital signature\r
 142 Content-Disposition: attachment\r
 143 \r
 144 -----BEGIN PGP SIGNATURE-----\r
 145 Version: GnuPG v1.4.10 (GNU/Linux)\r
 146 \r
 147 iQIcBAEBCAAGBQJLUiZxAAoJEO00zqvie6q8JFEP+wWXuxzRnsbpF3Usdo5H7Z9y\r
 148 GYO0HZ1CXqmp7YeyxEXJRNAL+UgldbOIKE/fkMDwEuKo4U4ebZmODDBPNNVZtkyw\r
 149 EPl6YErNqOW1O4AUcv/QdMAb8nK46a9gUg5H91zNJaSAU10auDE5HXLoTFkF8wBe\r
 150 QVlkbGWWD9YWN1abkVhRNNMB/A5Utq65Ecarwm+RMObbIL/7puSjoGqaxQM/44hQ\r
 151 jRqcCyRCnRsgXS4cLMUdUPwnC9reIrMY6VYCaOIFcPHCV0yjZfcJfX+bkRglpJzB\r
 152 LV4aED92XwCXM7XPCqLJlJhB+la/+h3o+h0sYu8EASUPe09Pg5zczc7kOq5IBGAd\r
 153 5jRJhjqUlGFuYmazQ6CJG0D9lfO9+S/95QItRIs3uCgsbciervxYCB6XrpCUNVNB\r
 154 IrqqIrJwdOixN3/uxk0jTuwTQBOLQnNuTJ4egy++ZESuUiIUJ2L7XB3jKfWvBp0k\r
 155 SjcjNmQxQPQSlQMhhKvOBH8M+2OrgbsTek0MfBL3yO2TBR8dszzErIO0PZS27bq6\r
 156 5JEWpgYHOBZeuXQYHJ8zjuSTOnzjAJagRdtz+jXQcwmQtL+hpoGEdvZSqdjw+SHq\r
 157 1wlYNHg90OLlUgndi3lXRRph0Xhe5dGfK0K29AcLvKvzmp7pj9TuhBXus5FsqQUr\r
 158 glNfFz2kRsznf8Cocgsh\r
 159 =wI3m\r
 160 -----END PGP SIGNATURE-----\r
 161 \r
 162 --VS++wcV0S1rZb1Fb--\r