Re: [PATCH 0/4] Allow specifying alternate names for addresses in other_email
[notmuch-archives.git] / b5 / e899c8cfc28d7bf4012489f0790cea66884584
1 Return-Path: <pieter@praet.org>\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 057E0431FAF\r
6         for <notmuch@notmuchmail.org>; Thu, 19 Jan 2012 11:15:47 -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 PdeSgL6YunKc for <notmuch@notmuchmail.org>;\r
16         Thu, 19 Jan 2012 11:15:46 -0800 (PST)\r
17 Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com\r
18         [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
19         (No client certificate requested)\r
20         by olra.theworths.org (Postfix) with ESMTPS id 458B3431FAE\r
21         for <notmuch@notmuchmail.org>; Thu, 19 Jan 2012 11:15:46 -0800 (PST)\r
22 Received: by wibhr12 with SMTP id hr12so256910wib.26\r
23         for <notmuch@notmuchmail.org>; Thu, 19 Jan 2012 11:15:45 -0800 (PST)\r
24 Received: by 10.180.100.234 with SMTP id fb10mr41667513wib.5.1327000545027;\r
25         Thu, 19 Jan 2012 11:15:45 -0800 (PST)\r
26 Received: from localhost ([109.131.97.13])\r
27         by mx.google.com with ESMTPS id q7sm29679266wix.5.2012.01.19.11.15.43\r
28         (version=TLSv1/SSLv3 cipher=OTHER);\r
29         Thu, 19 Jan 2012 11:15:44 -0800 (PST)\r
30 From: Pieter Praet <pieter@praet.org>\r
31 To: Aaron Ecay <aaronecay@gmail.com>, David Edmondson <dme@dme.org>\r
32 Subject: Re: [PATCH] v2 [RFC] emacs: merge overhauled\r
33         `notmuch-cycle-notmuch-buffers' into `notmuch'\r
34 In-Reply-To: <m262g864dz.fsf@wal122.wireless-pennnet.upenn.edu>\r
35 References: <87r4yza95m.fsf@praet.org>\r
36         <1326732415-21894-1-git-send-email-pieter@praet.org>\r
37         <cun39bftw9b.fsf@hotblack-desiato.hh.sledj.net>\r
38         <87fwfd8h0i.fsf@praet.org>\r
39         <cunk44pmi7k.fsf@hotblack-desiato.hh.sledj.net>\r
40         <87obu19pfo.fsf@praet.org>\r
41         <cunhaztmalq.fsf@hotblack-desiato.hh.sledj.net>\r
42         <cunboq1mad1.fsf@hotblack-desiato.hh.sledj.net>\r
43         <87sjjdp1f1.fsf@praet.org>\r
44         <m262g864dz.fsf@wal122.wireless-pennnet.upenn.edu>\r
45 User-Agent: Notmuch/0.11+99~gab86e73 (http://notmuchmail.org) Emacs/23.3.1\r
46         (x86_64-unknown-linux-gnu)\r
47 Date: Thu, 19 Jan 2012 20:13:53 +0100\r
48 Message-ID: <87hazro68e.fsf@praet.org>\r
49 MIME-Version: 1.0\r
50 Content-Type: text/plain; charset=utf-8\r
51 Content-Transfer-Encoding: quoted-printable\r
52 Cc: Notmuch Mail <notmuch@notmuchmail.org>\r
53 X-BeenThere: notmuch@notmuchmail.org\r
54 X-Mailman-Version: 2.1.13\r
55 Precedence: list\r
56 List-Id: "Use and development of the notmuch mail system."\r
57         <notmuch.notmuchmail.org>\r
58 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
59         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
60 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
61 List-Post: <mailto:notmuch@notmuchmail.org>\r
62 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
63 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
64         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
65 X-List-Received-Date: Thu, 19 Jan 2012 19:15:47 -0000\r
66 \r
67 On Wed, 18 Jan 2012 17:18:48 -0500, Aaron Ecay <aaronecay@gmail.com> wrote:\r
68 > On Wed, 18 Jan 2012 14:48:02 +0100, Pieter Praet <pieter@praet.org> wrote:\r
69 > > My original intent of conserving a key(chord) [1] (which in\r
70 > > retrospect was a fairly pointless exercise in and of itself\r
71 > > [2,3]) seems to have inconspicuously morphed into an equally\r
72 > > questionable crusade [4] against the `cl' package.\r
73 > >=20\r
74 > > As long there's other functions in Notmuch depending on\r
75 > > compile-time `cl', there's really no incentive whatsoever\r
76 > > to replace your perfectly fine solution.\r
77 >=20\r
78 > (This is not strictly related to the immediate issue of these patches,\r
79 > but now seems as good a time as any to discuss it.)\r
80 >=20\r
81 > Compile-time dependencies on =E2=80=98cl=E2=80=99 are absolutely not a pr=\r
82 oblem.\r
83 > Virtually every major elisp program depends on cl at compile time.\r
84 > Runtime dependencies are not allowed in code distributed with emacs\r
85 > because of RMS=E2=80=99s conservativism[1].\r
86 >=20\r
87 > Since notmuch isn=E2=80=99t distributed with emacs and has no aspirations=\r
88  to\r
89 > ever be, the project could decide to require cl at runtime.  Many\r
90 > elisp programs do.  (A quick grep through my .emacs.d folder turns up\r
91 > anything.el and clojure-mode as two large/=E2=80=9Cmainstream=E2=80=9D pr=\r
92 ojects that\r
93 > do, as well as at least a dozen smaller utility files.)  So many emacs\r
94 > users have cl loaded all the time when they are using emacs.  But\r
95 > unless the project (i.e. us) decides explicitly =E2=80=9Cruntime cl is OK=\r
96 =E2=80=9D (or\r
97 > perhaps =E2=80=9Cit is not=E2=80=9D), contributors will always go back an=\r
98 d forth over\r
99 > using it.  To avoid patch and review churn, we ought to decide which\r
100 > of these we pick (and I vote for allowing runtime use.)\r
101 >=20\r
102 \r
103 Consider me thoroughly convinced :)\r
104 \r
105 No point in trying to conserve resources if they're already spent.\r
106 \r
107 +1 for explicitly allowing runtime `cl'.\r
108 \r
109 \r
110 > Aaron\r
111 >=20\r
112 > Footnotes:\r
113 > [1] He specifically objects to the way that the cl package uses keyword\r
114 >     arguments, calling it un-Elisp-like.  He has resisted past efforts\r
115 >     to merge cl functions into Elisp core, although they are slowly\r
116 >     diffusing across the barrier.\r
117 >=20\r
118 > --=20\r
119 > Aaron Ecay\r
120 \r
121 \r
122 Peace\r
123 \r
124 --=20\r
125 Pieter\r