[PATCH 4/4] Update NEWS for user.other_name
[notmuch-archives.git] / d6 / e715526d2fcd39a9661c3d1fe9cab4edc5424d
1 Return-Path: <tomi.ollila@iki.fi>\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 B8BAF431FB6\r
6         for <notmuch@notmuchmail.org>; Thu, 17 May 2012 23:59:19 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: 0\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
12         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 uBdPgxWwq+Wi for <notmuch@notmuchmail.org>;\r
16         Thu, 17 May 2012 23:59:18 -0700 (PDT)\r
17 Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
18         by olra.theworths.org (Postfix) with ESMTP id 7122A431FAE\r
19         for <notmuch@notmuchmail.org>; Thu, 17 May 2012 23:59:18 -0700 (PDT)\r
20 Received: by guru.guru-group.fi (Postfix, from userid 501)\r
21         id 3E18D100639; Fri, 18 May 2012 09:59:27 +0300 (EEST)\r
22 From: Tomi Ollila <tomi.ollila@iki.fi>\r
23 To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,\r
24         Notmuch Mail <notmuch@notmuchmail.org>\r
25 Subject: Re: [PATCH 4/6] cli: intialize crypto structure in show and reply\r
26 In-Reply-To: <4FB572DA.8040906@fifthhorseman.net>\r
27 References: <1337205359-2444-1-git-send-email-jrollins@finestructure.net>\r
28         <1337205359-2444-2-git-send-email-jrollins@finestructure.net>\r
29         <1337205359-2444-3-git-send-email-jrollins@finestructure.net>\r
30         <1337205359-2444-4-git-send-email-jrollins@finestructure.net>\r
31         <1337205359-2444-5-git-send-email-jrollins@finestructure.net>\r
32         <8762bvi70k.fsf@nikula.org>\r
33         <877gwaeve1.fsf@servo.finestructure.net>\r
34         <CAB+hUn9DdeaFj-hUNb_c1V3QLsbWjsE7_hpuOpDqWseayASdKQ@mail.gmail.com>\r
35         <87aa16daeq.fsf@servo.finestructure.net>\r
36         <4FB572DA.8040906@fifthhorseman.net>\r
37 User-Agent: Notmuch/0.13~rc1+23~gefd2384 (http://notmuchmail.org) Emacs/23.1.1\r
38         (x86_64-redhat-linux-gnu)\r
39 X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
40         $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
41         !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
42 Date: Fri, 18 May 2012 09:59:27 +0300\r
43 Message-ID: <m28vgqdlf4.fsf@guru.guru-group.fi>\r
44 MIME-Version: 1.0\r
45 Content-Type: text/plain; charset=us-ascii\r
46 X-BeenThere: notmuch@notmuchmail.org\r
47 X-Mailman-Version: 2.1.13\r
48 Precedence: list\r
49 List-Id: "Use and development of the notmuch mail system."\r
50         <notmuch.notmuchmail.org>\r
51 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
52         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
53 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
54 List-Post: <mailto:notmuch@notmuchmail.org>\r
55 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
56 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
57         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
58 X-List-Received-Date: Fri, 18 May 2012 06:59:19 -0000\r
59 \r
60 On Fri, May 18 2012, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:\r
61 \r
62 >\r
63 > The real tradeoff in this choice is whether we prefer:\r
64 >\r
65 >  a) more compact code to facilitate quick reading by experts\r
66 >\r
67 >    or\r
68 >\r
69 >  b) more verbose code to facilitate comprehension by the non-expert.\r
70 >\r
71 > I started this discussion leaning strongly toward the (b) perspective.\r
72 > But now that i know the relevant bits of the standard, i can sympathize\r
73 > with the (a) perspective as well :P\r
74 >\r
75 > Overall, i think i'm still in the (b) camp.  But i think it's more\r
76 > important that we don't allow dithering over this issue to prevent the\r
77 > inclusion of this patch series, which is a step in the right direction\r
78 > for handling S/MIME messages as well as PGP/MIME.\r
79 \r
80 I also think it is good to see explicit initializations when those aren't\r
81 needed but clarifies the code. After all it doesn't generate any extra\r
82 code to the target module. Also the &(params->crypto) is good from\r
83 clarification point of view.\r
84 \r
85 Austin's .crypto { ... } initialization looks good & clear; In case there\r
86 will be new version of this patch series I'd like to see that used...\r
87 \r
88 >       --dkg\r
89 >\r
90 > PS gcc's -pedantic argument provides the following warning:\r
91 >\r
92 >  error: ISO C90 forbids specifying subobject to initialize\r
93 >\r
94 > So we probably want to specify -std=c99 at least to ensure our choice of\r
95 > subobject initialization is respected.\r
96 \r
97 In order to do that id:"cover.1325977940.git.jani@nikula.org" needs to\r
98 be applied (and probably rebased).\r
99 \r
100 > [0] http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf\r
101 \r
102 Tomi\r