Re: Flat search and threaded views
[notmuch-archives.git] / 38 / 26eaa8b77de0b53929d752b05c48cefd5efd5d
1 Return-Path: <jrollins@finestructure.net>\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 585FB431FD0\r
6         for <notmuch@notmuchmail.org>; Mon, 26 Dec 2011 14:24:20 -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: -2.29\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5\r
12         tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01] 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 8TWPZMtupvUd for <notmuch@notmuchmail.org>;\r
16         Mon, 26 Dec 2011 14:24:19 -0800 (PST)\r
17 Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu\r
18         [131.215.239.19])\r
19         by olra.theworths.org (Postfix) with ESMTP id C6E58431FB6\r
20         for <notmuch@notmuchmail.org>; Mon, 26 Dec 2011 14:24:19 -0800 (PST)\r
21 Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1])\r
22         by fire-doxen-postvirus (Postfix) with ESMTP id 823272E50C1E;\r
23         Mon, 26 Dec 2011 14:24:19 -0800 (PST)\r
24 X-Spam-Scanned: at Caltech-IMSS on fire-doxen by amavisd-new\r
25 Received: from finestructure.net (99-7-169-236.lightspeed.sntcca.sbcglobal.net\r
26         [99.7.169.236]) (Authenticated sender: jrollins)\r
27         by fire-doxen-submit (Postfix) with ESMTP id B8EF02E50AAC;\r
28         Mon, 26 Dec 2011 14:24:15 -0800 (PST)\r
29 Received: by finestructure.net (Postfix, from userid 1000)\r
30         id 6093F16C7; Mon, 26 Dec 2011 14:24:14 -0800 (PST)\r
31 From: Jameson Graef Rollins <jrollins@finestructure.net>\r
32 To: David Edmondson <dme@dme.org>,\r
33         Dmitry Kurochkin <dmitry.kurochkin@gmail.com>, notmuch@notmuchmail.org\r
34 Subject: Re: [RFC][PATCH v4] emacs: Re-implement advance/rewind functions of\r
35         notmuch-show-mode.\r
36 In-Reply-To: <cun39c7t2mi.fsf@hotblack-desiato.hh.sledj.net>\r
37 References: <id:"1324553312-10972-1-git-send-email-dme@dme.org">\r
38         <1324665712-2419-1-git-send-email-dme@dme.org>\r
39         <87ipl7kt82.fsf@gmail.com>\r
40         <cunpqfbtxu2.fsf@hotblack-desiato.hh.sledj.net>\r
41         <87fwg71tdo.fsf@gmail.com>\r
42         <cun39c7t2mi.fsf@hotblack-desiato.hh.sledj.net>\r
43 User-Agent: Notmuch/0.10.2+127~g6689686 (http://notmuchmail.org) Emacs/23.3.1\r
44         (x86_64-pc-linux-gnu)\r
45 Date: Mon, 26 Dec 2011 14:24:11 -0800\r
46 Message-ID: <87zkefhsz8.fsf@servo.finestructure.net>\r
47 MIME-Version: 1.0\r
48 Content-Type: multipart/signed; boundary="=-=-=";\r
49         micalg=pgp-sha256; protocol="application/pgp-signature"\r
50 X-BeenThere: notmuch@notmuchmail.org\r
51 X-Mailman-Version: 2.1.13\r
52 Precedence: list\r
53 List-Id: "Use and development of the notmuch mail system."\r
54         <notmuch.notmuchmail.org>\r
55 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
56         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
57 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
58 List-Post: <mailto:notmuch@notmuchmail.org>\r
59 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
60 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
61         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
62 X-List-Received-Date: Mon, 26 Dec 2011 22:24:20 -0000\r
63 \r
64 --=-=-=\r
65 Content-Transfer-Encoding: quoted-printable\r
66 \r
67 On Mon, 26 Dec 2011 22:00:21 +0000, David Edmondson <dme@dme.org> wrote:\r
68 > Understood. For me this fell inside the 'trivial other change' boundary.\r
69 \r
70 Fwiw, I don't remember there ever being such a distinction.  I think\r
71 we've always insisted that unrelated changes should be excluded.  As a\r
72 general rule, I think all patches should be as atomic as they can\r
73 possibly be.  I would much rather have more smaller, atomic patches than\r
74 fewer longer, composite ones.\r
75 \r
76 > > And can you please explain why `when' is better than `if' here?  Then I\r
77 > > will know which one to use the next time :)\r
78 >=20\r
79 > `if' allows only a single statement for `then', which results in code lik=\r
80 e:\r
81 >=20\r
82 >      (if foo\r
83 >         (progn\r
84 >           (this)\r
85 >           (that)\r
86 >           (theother)))\r
87 >=20\r
88 > so if there is no `else' clause I've been preferring:\r
89 >=20\r
90 >       (when foo\r
91 >         (this)\r
92 >         (that)\r
93 >         (theother))\r
94 >=20\r
95 > but that's obviously personal and not important in this specific case.\r
96 \r
97 That's good.  I like it.  The if construction always annoyed me a bit\r
98 for this reason.  The when construction is definitely cleaner.\r
99 \r
100 jamie.\r
101 \r
102 --=-=-=\r
103 Content-Type: application/pgp-signature\r
104 \r
105 -----BEGIN PGP SIGNATURE-----\r
106 Version: GnuPG v1.4.11 (GNU/Linux)\r
107 \r
108 iQIcBAEBCAAGBQJO+PQLAAoJEO00zqvie6q8ZSoP/1mi5uSPUbJ/X0c+dqpmGjI/\r
109 htsMzaIgAdN47+hQFmvdsVIKq4MUwY6eWjbLYFvxcCZSVhAcVPIKjTEup6aJ4DVd\r
110 jXiCGIAvR4mdZFzx67qt7HCC/mdBRMIvM8MvRszrqfpSc2K+ocv63hJGmA/EBKmN\r
111 Hg5ckCTOppHifCbFjSEDqNSm4SsjGRLEJYvu4TjOtDoPfJukKNyM0buTKkEAmSxF\r
112 rXcGVAzJ7N0A42XeRyFb7qyC9I94bJmDzBiYXf5Cx11N0sssdUJ5/UgZiDNQB7Wl\r
113 MN422tYvdKVHK746sQc7kGDA9MfDqGDTmpgseAtTX+D0J+ud0Pa3+5W9Ft1Imf0B\r
114 GrHYSbevhFqVIJcJoRr5ePfTeKnbR37SvJvQnSWA9xgXZAoOUXTTVUmybVZ176+v\r
115 5UAF8bsOBFji4MVHXjD5ewgGEdW/tikQ13SGPeeLXcHm/8UTGPIEU/+6J1CDYHOh\r
116 WI/E+5dtSMEUK5b994xlpDlWnGR85Z2SGXGM3XqF5tk9/U9odSUvrQ0riWQN6WHL\r
117 VAq2Sh8+1fcXvGJ0zuCgQCB5d4xjf85XY24YTVvU2cKtc/70WI91pF2/LZmw6r/Z\r
118 UwXqR3+a29NKarbKmwGWn9SxE9EtX9Ozq91qgpXAOm1BjNhtxAHK8HgDXbpjHR/d\r
119 CTY1ZiLRliSSlMTPhszu\r
120 =GDVO\r
121 -----END PGP SIGNATURE-----\r
122 --=-=-=--\r