Re: notmuch.el: controlling what does and doesn't get expanded in searches
[notmuch-archives.git] / 26 / fc748bd2fbcf4c7ea3c09c5a47f13b5067b05e
1 Return-Path: <amdragon@mit.edu>\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 F4236431FAF\r
6         for <notmuch@notmuchmail.org>; Wed, 18 Jan 2012 16:48:27 -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: -0.7\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\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 jrzg0L1AZ7bV for <notmuch@notmuchmail.org>;\r
16         Wed, 18 Jan 2012 16:48:27 -0800 (PST)\r
17 Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU\r
18         [18.7.68.37])\r
19         by olra.theworths.org (Postfix) with ESMTP id 717B2431FAE\r
20         for <notmuch@notmuchmail.org>; Wed, 18 Jan 2012 16:48:27 -0800 (PST)\r
21 X-AuditID: 12074425-b7f4a6d0000008e0-f6-4f17685bf4b9\r
22 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43])\r
23         by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP\r
24         id 91.C7.02272.B58671F4; Wed, 18 Jan 2012 19:48:27 -0500 (EST)\r
25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
26         by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id q0J0mQIF015620; \r
27         Wed, 18 Jan 2012 19:48:26 -0500\r
28 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
29         (authenticated bits=0)\r
30         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
31         by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q0J0mPS8017989\r
32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
33         Wed, 18 Jan 2012 19:48:25 -0500 (EST)\r
34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77)\r
35         (envelope-from <amdragon@mit.edu>)\r
36         id 1RngAk-0001yX-7R; Wed, 18 Jan 2012 19:48:10 -0500\r
37 Date: Wed, 18 Jan 2012 19:48:10 -0500\r
38 From: Austin Clements <amdragon@MIT.EDU>\r
39 To: Aaron Ecay <aaronecay@gmail.com>\r
40 Subject: Re: [PATCH] v2 [RFC] emacs: merge overhauled\r
41         `notmuch-cycle-notmuch-buffers' into `notmuch'\r
42 Message-ID: <20120119004810.GI16740@mit.edu>\r
43 References: <87r4yza95m.fsf@praet.org>\r
44         <1326732415-21894-1-git-send-email-pieter@praet.org>\r
45         <cun39bftw9b.fsf@hotblack-desiato.hh.sledj.net>\r
46         <87fwfd8h0i.fsf@praet.org>\r
47         <cunk44pmi7k.fsf@hotblack-desiato.hh.sledj.net>\r
48         <87obu19pfo.fsf@praet.org>\r
49         <cunhaztmalq.fsf@hotblack-desiato.hh.sledj.net>\r
50         <cunboq1mad1.fsf@hotblack-desiato.hh.sledj.net>\r
51         <87sjjdp1f1.fsf@praet.org>\r
52         <m262g864dz.fsf@wal122.wireless-pennnet.upenn.edu>\r
53 MIME-Version: 1.0\r
54 Content-Type: text/plain; charset=utf-8\r
55 Content-Disposition: inline\r
56 Content-Transfer-Encoding: 8bit\r
57 In-Reply-To: <m262g864dz.fsf@wal122.wireless-pennnet.upenn.edu>\r
58 User-Agent: Mutt/1.5.21 (2010-09-15)\r
59 X-Brightmail-Tracker:\r
60  H4sIAAAAAAAAA+NgFtrDKsWRmVeSWpSXmKPExsUixCmqrRudIe5v8Pk/p8W05V/YLfbd2cJk\r
61         cf3mTGaL369vMDuweOx6/pfJY+esu+wez1bdYvbo2HeZNYAlissmJTUnsyy1SN8ugStjW+dc\r
62         5oJu7oqJtztYGxi/cnQxcnJICJhInG98wgZhi0lcuLceyObiEBLYxygx7fIWZghnA5CzaymU\r
63         c5JJYuGWfiYIZwmjxMGJ35hB+lkEVCWafy9nB7HZBDQktu1fzghiiwioSMyeNx/MZhYolrh3\r
64         8AJQDQeHsECaxPWPliBhXgEdiYMdV9ghZm5klvh65jk7REJQ4uTMJywQveoSf+ZdYgbpZRaQ\r
65         llj+jwMiLC/RvHU22AmcAvYSU7+3g70jCrR2ysltbBMYhWchmTQLyaRZCJNmIZm0gJFlFaNs\r
66         Sm6Vbm5iZk5xarJucXJiXl5qka6FXm5miV5qSukmRlDEsLuo7mCccEjpEKMAB6MSD2+EiLi/\r
67         EGtiWXFl7iFGSQ4mJVFe33SgEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHenSZAOd6UxMqq1KJ8\r
68         mJQ0B4uSOK+m1js/IYH0xJLU7NTUgtQimKwGB4fA3SW9GxilWPLy81KVJHj5QRYIFqWmp1ak\r
69         ZeaUIJQycXCCLOIBWvQapIa3uCAxtzgzHSJ/ilFRSpz3PEhCACSRUZoH1wtLdK8YxYHeEub9\r
70         BFLFA0yScN2vgAYzAQ32aBIDGVySiJCSamBsufN6Q+PSBzsP53rxGbx4k6Lo9Zk5j2PlzsN/\r
71         QxlWWm2csz1nyZFWgbuWXc6TVbl2ZLjeehRZ1X13fnf5Go1Ph+6UJMpOnLWohXepQX/sqWUv\r
72         e3PO+Pd+aJowUVpPQmyexdbEGuEl5zdukt330zWmUeiAg+u/u02ZcgJG3Xs27m6Nm67Ze+OX\r
73         EktxRqKhFnNRcSIAaiXxq08DAAA=\r
74 Cc: Notmuch Mail <notmuch@notmuchmail.org>, Pieter Praet <pieter@praet.org>\r
75 X-BeenThere: notmuch@notmuchmail.org\r
76 X-Mailman-Version: 2.1.13\r
77 Precedence: list\r
78 List-Id: "Use and development of the notmuch mail system."\r
79         <notmuch.notmuchmail.org>\r
80 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
81         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
82 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
83 List-Post: <mailto:notmuch@notmuchmail.org>\r
84 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
85 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
86         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
87 X-List-Received-Date: Thu, 19 Jan 2012 00:48:28 -0000\r
88 \r
89 Quoth Aaron Ecay on Jan 18 at  5:18 pm:\r
90 > Compile-time dependencies on ‘cl’ are absolutely not a problem.\r
91 > Virtually every major elisp program depends on cl at compile time.\r
92 > Runtime dependencies are not allowed in code distributed with emacs\r
93 > because of RMS’s conservativism[1].\r
94\r
95 > Since notmuch isn’t distributed with emacs and has no aspirations to\r
96 > ever be, the project could decide to require cl at runtime.  Many\r
97 > elisp programs do.  (A quick grep through my .emacs.d folder turns up\r
98 > anything.el and clojure-mode as two large/“mainstream” projects that\r
99 > do, as well as at least a dozen smaller utility files.)  So many emacs\r
100 > users have cl loaded all the time when they are using emacs.  But\r
101 > unless the project (i.e. us) decides explicitly “runtime cl is OK” (or\r
102 > perhaps “it is not”), contributors will always go back and forth over\r
103 > using it.  To avoid patch and review churn, we ought to decide which\r
104 > of these we pick (and I vote for allowing runtime use.)\r
105 \r
106 I agree with Aaron.  There's no excuse for some of the functionality\r
107 that can only be found in cl to be missing from core Emacs and it's\r
108 ridiculous to re-implement it time and again (I count at least five\r
109 obvious reimplementations of remove-if in code shipped with Emacs).\r
110 There are a lot of compelling reasons to use cl and I'm not aware of\r
111 any good technical reasons why notmuch shouldn't.\r