--- /dev/null
+Return-Path: <jrollins@finestructure.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id EE58E431FBC\r
+ for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 12:50:05 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -1.762\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5\r
+ tests=[AWL=-1.763, BAYES_50=0.001] autolearn=ham\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id m0SsE2X1zEaW for <notmuch@notmuchmail.org>;\r
+ Sat, 16 Jan 2010 12:50:05 -0800 (PST)\r
+Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7])\r
+ by olra.theworths.org (Postfix) with ESMTP id 24EAF431FAE\r
+ for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 12:50:05 -0800 (PST)\r
+Received: from servo.finestructure.net (lair.fifthhorseman.net\r
+ [216.254.116.241])\r
+ (user=jgr2110 author=jrollins@finestructure.net mech=PLAIN bits=0)\r
+ by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o0GKnwX6024902\r
+ (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT)\r
+ for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 15:50:03 -0500 (EST)\r
+Received: from jrollins by servo.finestructure.net with local (Exim 4.71)\r
+ (envelope-from <jrollins@finestructure.net>) id 1NWFal-0006ra-V9\r
+ for notmuch@notmuchmail.org; Sat, 16 Jan 2010 15:49:55 -0500\r
+Date: Sat, 16 Jan 2010 15:49:55 -0500\r
+From: Jameson Rollins <jrollins@finestructure.net>\r
+To: Notmuch Mail <notmuch@notmuchmail.org>\r
+Message-ID: <20100116204955.GA858@finestructure.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; micalg=pgp-sha256;\r
+ protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb"\r
+Content-Disposition: inline\r
+User-Agent: Mutt/1.5.20 (2009-06-14)\r
+X-No-Spam-Score: Local\r
+X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7\r
+Subject: [notmuch] proposal for more streamlined mail flow in notmuch\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sat, 16 Jan 2010 20:50:06 -0000\r
+\r
+\r
+--VS++wcV0S1rZb1Fb\r
+Content-Type: text/plain; charset=us-ascii\r
+Content-Disposition: inline\r
+\r
+I would like to put forth here a proposal for a couple of changes to\r
+notmuch that I believe will considerably streamline message handling\r
+and new message flow through notmuch. Notmuch is still new and I\r
+believe it hasn't quite figured out the best way to handle message\r
+flow in the new mail handling paradigm that it is working. This is a\r
+proposal to fix that.\r
+\r
+I believe that most people are syncing their mail from remote IMAP or\r
+POP servers to local maildirs (via offlineimap for instance), and that\r
+most people's IMAP servers have limited storage capacity. This\r
+practically means that people can not keep all of their mail in a\r
+single directory. However, notmuch currently basically assumes that\r
+this is what is happening. In order to keep synced maildirs from\r
+growing out of hand, messages need to be either deleted or moved out\r
+of the "inbox" where they initially show up. This is why it was so\r
+important for notmuch to get support for deletion/renaming/moving of\r
+messages.\r
+\r
+However, we still need to get notmuch to fundamentally understand this\r
+flow (mail comes into inbox, and is then moved elsewhere), and provide\r
+the functions to easily facilitate this flow for users.\r
+\r
+To this end, here is how I believe the notmuch flow should look:\r
+\r
+- New messages are delivered into a maildir "inbox". When notmuch new\r
+ is run, these new messages are tagged 'inbox' and 'unread'.\r
+\r
+- When a user views a message with their reader, the 'unread' tag is\r
+ automatically removed, the maildir S flag is added and the message\r
+ is moved from inbox/new to inbox/cur.\r
+\r
+- If the user wishes to delete a message, a 'delete' tag is added to\r
+ the message. If the user does a "purge", all messages tagged\r
+ 'delete' are erased from disk and/or a "delete hook" is run.\r
+\r
+- If the user wishes to archive a message the 'inbox' tag is removed\r
+ and the messages is actually moved from the inbox maildir into an\r
+ archive maildir and/or an "archive hook" is run.\r
+\r
+To fascilitate this, two new functions should be implemented at the\r
+notmuch CLI level, so that things don't get fractured by different\r
+mail reader implementations:\r
+\r
+notmuch purge\r
+\r
+ delete all 'delete' tagged messages, and/or execute "delete hooks"\r
+\r
+notmuch archive <search-terms>\r
+\r
+ remove 'inbox' flags from messages and move messages an archive\r
+ maildir, and/or execute "archive hooks"\r
+\r
+I believe this is a simple, intuitive flow, that will be easy to\r
+understand and work with by pretty much all users, but is still very\r
+nicely extensible for advanced users. For instance, a delete hook\r
+might move the message to a trash instead of deleting it outright, or\r
+an "archive hook" could filter archived messages into folders. Hooks\r
+could also be used to do nothing to messages other than just modifying\r
+the tags (which would completely mimic the current notmuch behavior).\r
+The config file could be kept very simple (only two hooks would need\r
+to be defined), without having to move to some crazy script-based\r
+config scheme (like lua) that is overly complicated and very hard for\r
+new users to understand. It would also great simplify the mail\r
+readers themselves (like the emacs UI), because it would greatly\r
+reduce the number of commands (ie. essentially just "view", "delete",\r
+"archive", or "search").\r
+\r
+What do folks think of this proposal? I am convinced that this flow\r
+is simple, would be intuitive to new users, and extensible such that\r
+it could provide the functionality that anyone could desire. I would\r
+be curious to hear of anyone interested in using notmuch who thinks\r
+they could *not* achieve the mail flow that they desire with this\r
+scheme.\r
+\r
+Any and all feedback on this proposal is welcome. If people think\r
+this flow is a good idea, I would be psyched to start fleshing it out.\r
+\r
+jamie.\r
+\r
+--VS++wcV0S1rZb1Fb\r
+Content-Type: application/pgp-signature; name="signature.asc"\r
+Content-Description: Digital signature\r
+Content-Disposition: attachment\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.10 (GNU/Linux)\r
+\r
+iQIcBAEBCAAGBQJLUiZxAAoJEO00zqvie6q8JFEP+wWXuxzRnsbpF3Usdo5H7Z9y\r
+GYO0HZ1CXqmp7YeyxEXJRNAL+UgldbOIKE/fkMDwEuKo4U4ebZmODDBPNNVZtkyw\r
+EPl6YErNqOW1O4AUcv/QdMAb8nK46a9gUg5H91zNJaSAU10auDE5HXLoTFkF8wBe\r
+QVlkbGWWD9YWN1abkVhRNNMB/A5Utq65Ecarwm+RMObbIL/7puSjoGqaxQM/44hQ\r
+jRqcCyRCnRsgXS4cLMUdUPwnC9reIrMY6VYCaOIFcPHCV0yjZfcJfX+bkRglpJzB\r
+LV4aED92XwCXM7XPCqLJlJhB+la/+h3o+h0sYu8EASUPe09Pg5zczc7kOq5IBGAd\r
+5jRJhjqUlGFuYmazQ6CJG0D9lfO9+S/95QItRIs3uCgsbciervxYCB6XrpCUNVNB\r
+IrqqIrJwdOixN3/uxk0jTuwTQBOLQnNuTJ4egy++ZESuUiIUJ2L7XB3jKfWvBp0k\r
+SjcjNmQxQPQSlQMhhKvOBH8M+2OrgbsTek0MfBL3yO2TBR8dszzErIO0PZS27bq6\r
+5JEWpgYHOBZeuXQYHJ8zjuSTOnzjAJagRdtz+jXQcwmQtL+hpoGEdvZSqdjw+SHq\r
+1wlYNHg90OLlUgndi3lXRRph0Xhe5dGfK0K29AcLvKvzmp7pj9TuhBXus5FsqQUr\r
+glNfFz2kRsznf8Cocgsh\r
+=wI3m\r
+-----END PGP SIGNATURE-----\r
+\r
+--VS++wcV0S1rZb1Fb--\r
projects / notmuch-archives.git / commitdiff