Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into...

diff --git a/26/fc748bd2fbcf4c7ea3c09c5a47f13b5067b05e b/26/fc748bd2fbcf4c7ea3c09c5a47f13b5067b05e
new file mode 100644 (file)
index 0000000..4be8646
--- /dev/null
+++ b/26/fc748bd2fbcf4c7ea3c09c5a47f13b5067b05e
@@ -0,0 +1,111 @@
+Return-Path: <amdragon@mit.edu>\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 F4236431FAF\r
+       for <notmuch@notmuchmail.org>; Wed, 18 Jan 2012 16:48:27 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\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 jrzg0L1AZ7bV for <notmuch@notmuchmail.org>;\r
+       Wed, 18 Jan 2012 16:48:27 -0800 (PST)\r
+Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU\r
+       [18.7.68.37])\r
+       by olra.theworths.org (Postfix) with ESMTP id 717B2431FAE\r
+       for <notmuch@notmuchmail.org>; Wed, 18 Jan 2012 16:48:27 -0800 (PST)\r
+X-AuditID: 12074425-b7f4a6d0000008e0-f6-4f17685bf4b9\r
+Received: from mailhub-auth-3.mit.edu ( [18.9.21.43])\r
+       by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP\r
+       id 91.C7.02272.B58671F4; Wed, 18 Jan 2012 19:48:27 -0500 (EST)\r
+Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
+       by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id q0J0mQIF015620; \r
+       Wed, 18 Jan 2012 19:48:26 -0500\r
+Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
+       (authenticated bits=0)\r
+       (User authenticated as amdragon@ATHENA.MIT.EDU)\r
+       by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q0J0mPS8017989\r
+       (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
+       Wed, 18 Jan 2012 19:48:25 -0500 (EST)\r
+Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77)\r
+       (envelope-from <amdragon@mit.edu>)\r
+       id 1RngAk-0001yX-7R; Wed, 18 Jan 2012 19:48:10 -0500\r
+Date: Wed, 18 Jan 2012 19:48:10 -0500\r
+From: Austin Clements <amdragon@MIT.EDU>\r
+To: Aaron Ecay <aaronecay@gmail.com>\r
+Subject: Re: [PATCH] v2 [RFC] emacs: merge overhauled\r
+       `notmuch-cycle-notmuch-buffers' into `notmuch'\r
+Message-ID: <20120119004810.GI16740@mit.edu>\r
+References: <87r4yza95m.fsf@praet.org>\r
+       <1326732415-21894-1-git-send-email-pieter@praet.org>\r
+       <cun39bftw9b.fsf@hotblack-desiato.hh.sledj.net>\r
+       <87fwfd8h0i.fsf@praet.org>\r
+       <cunk44pmi7k.fsf@hotblack-desiato.hh.sledj.net>\r
+       <87obu19pfo.fsf@praet.org>\r
+       <cunhaztmalq.fsf@hotblack-desiato.hh.sledj.net>\r
+       <cunboq1mad1.fsf@hotblack-desiato.hh.sledj.net>\r
+       <87sjjdp1f1.fsf@praet.org>\r
+       <m262g864dz.fsf@wal122.wireless-pennnet.upenn.edu>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Disposition: inline\r
+Content-Transfer-Encoding: 8bit\r
+In-Reply-To: <m262g864dz.fsf@wal122.wireless-pennnet.upenn.edu>\r
+User-Agent: Mutt/1.5.21 (2010-09-15)\r
+X-Brightmail-Tracker:\r
+ H4sIAAAAAAAAA+NgFtrDKsWRmVeSWpSXmKPExsUixCmqrRudIe5v8Pk/p8W05V/YLfbd2cJk\r
+       cf3mTGaL369vMDuweOx6/pfJY+esu+wez1bdYvbo2HeZNYAlissmJTUnsyy1SN8ugStjW+dc\r
+       5oJu7oqJtztYGxi/cnQxcnJICJhInG98wgZhi0lcuLceyObiEBLYxygx7fIWZghnA5CzaymU\r
+       c5JJYuGWfiYIZwmjxMGJ35hB+lkEVCWafy9nB7HZBDQktu1fzghiiwioSMyeNx/MZhYolrh3\r
+       8AJQDQeHsECaxPWPliBhXgEdiYMdV9ghZm5klvh65jk7REJQ4uTMJywQveoSf+ZdYgbpZRaQ\r
+       llj+jwMiLC/RvHU22AmcAvYSU7+3g70jCrR2ysltbBMYhWchmTQLyaRZCJNmIZm0gJFlFaNs\r
+       Sm6Vbm5iZk5xarJucXJiXl5qka6FXm5miV5qSukmRlDEsLuo7mCccEjpEKMAB6MSD2+EiLi/\r
+       EGtiWXFl7iFGSQ4mJVFe33SgEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHenSZAOd6UxMqq1KJ8\r
+       mJQ0B4uSOK+m1js/IYH0xJLU7NTUgtQimKwGB4fA3SW9GxilWPLy81KVJHj5QRYIFqWmp1ak\r
+       ZeaUIJQycXCCLOIBWvQapIa3uCAxtzgzHSJ/ilFRSpz3PEhCACSRUZoH1wtLdK8YxYHeEub9\r
+       BFLFA0yScN2vgAYzAQ32aBIDGVySiJCSamBsufN6Q+PSBzsP53rxGbx4k6Lo9Zk5j2PlzsN/\r
+       QxlWWm2csz1nyZFWgbuWXc6TVbl2ZLjeehRZ1X13fnf5Go1Ph+6UJMpOnLWohXepQX/sqWUv\r
+       e3PO+Pd+aJowUVpPQmyexdbEGuEl5zdukt330zWmUeiAg+u/u02ZcgJG3Xs27m6Nm67Ze+OX\r
+       EktxRqKhFnNRcSIAaiXxq08DAAA=\r
+Cc: Notmuch Mail <notmuch@notmuchmail.org>, Pieter Praet <pieter@praet.org>\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: Thu, 19 Jan 2012 00:48:28 -0000\r
+\r
+Quoth Aaron Ecay on Jan 18 at  5:18 pm:\r
+> Compile-time dependencies on ‘cl’ are absolutely not a problem.\r
+> Virtually every major elisp program depends on cl at compile time.\r
+> Runtime dependencies are not allowed in code distributed with emacs\r
+> because of RMS’s conservativism[1].\r
+> \r
+> Since notmuch isn’t distributed with emacs and has no aspirations to\r
+> ever be, the project could decide to require cl at runtime.  Many\r
+> elisp programs do.  (A quick grep through my .emacs.d folder turns up\r
+> anything.el and clojure-mode as two large/“mainstream” projects that\r
+> do, as well as at least a dozen smaller utility files.)  So many emacs\r
+> users have cl loaded all the time when they are using emacs.  But\r
+> unless the project (i.e. us) decides explicitly “runtime cl is OK” (or\r
+> perhaps “it is not”), contributors will always go back and forth over\r
+> using it.  To avoid patch and review churn, we ought to decide which\r
+> of these we pick (and I vote for allowing runtime use.)\r
+\r
+I agree with Aaron.  There's no excuse for some of the functionality\r
+that can only be found in cl to be missing from core Emacs and it's\r
+ridiculous to re-implement it time and again (I count at least five\r
+obvious reimplementations of remove-if in code shipped with Emacs).\r
+There are a lot of compelling reasons to use cl and I'm not aware of\r
+any good technical reasons why notmuch shouldn't.\r