Re: Applying patches directly from emails?
[notmuch-archives.git] / 2d / 4dc5383787284566bb02e2fd080ab65435f3fb
1 Return-Path: <awg@xvx.ca>\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 10B66431E82\r
6         for <notmuch@notmuchmail.org>; Fri, 20 Jan 2012 09:22:14 -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 8jbKsv2tmKt3 for <notmuch@notmuchmail.org>;\r
16         Fri, 20 Jan 2012 09:22:13 -0800 (PST)\r
17 Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com\r
18         [209.85.214.53]) (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 BC8CD431E62\r
21         for <notmuch@notmuchmail.org>; Fri, 20 Jan 2012 09:22:12 -0800 (PST)\r
22 Received: by bkbzu17 with SMTP id zu17so692880bkb.26\r
23         for <notmuch@notmuchmail.org>; Fri, 20 Jan 2012 09:22:10 -0800 (PST)\r
24 MIME-Version: 1.0\r
25 Received: by 10.204.156.219 with SMTP id y27mr11952602bkw.71.1327080129943;\r
26         Fri, 20 Jan 2012 09:22:09 -0800 (PST)\r
27 Sender: awg@xvx.ca\r
28 Received: by 10.204.49.75 with HTTP; Fri, 20 Jan 2012 09:22:09 -0800 (PST)\r
29 X-Originating-IP: [208.77.198.202]\r
30 In-Reply-To: <m2mx9i3onw.fsf@wal122.wireless-pennnet.upenn.edu>\r
31 References: <1326995217-27423-1-git-send-email-awg+notmuch@xvx.ca>\r
32         <1326995217-27423-6-git-send-email-awg+notmuch@xvx.ca>\r
33         <m2k44n4jlz.fsf@wal122.wireless-pennnet.upenn.edu>\r
34         <CAMoJFUtn2Ls4maJGecY5Y8HzdOJSR6ZfVdUxnCZ6s4Jhq8r9yw@mail.gmail.com>\r
35         <m2mx9i3onw.fsf@wal122.wireless-pennnet.upenn.edu>\r
36 Date: Fri, 20 Jan 2012 10:22:09 -0700\r
37 X-Google-Sender-Auth: j5iO2a0ZjPQVbSzSfd6hyr5VZaw\r
38 Message-ID:\r
39  <CAMoJFUumHxLK8B1O99=t80C2X4-Z_hR0rOh83Ktk-192PB0uxA@mail.gmail.com>\r
40 Subject: Re: [PATCH v3 5/5] emacs: Use message-citation-line-format in reply\r
41 From: Adam Wolfe Gordon <awg+notmuch@xvx.ca>\r
42 To: Aaron Ecay <ecay@sas.upenn.edu>\r
43 Content-Type: text/plain; charset=windows-1252\r
44 Content-Transfer-Encoding: quoted-printable\r
45 Cc: notmuch@notmuchmail.org\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, 20 Jan 2012 17:22:14 -0000\r
59 \r
60 Erk, forgot to reply-all.  Aaron might get this twice.\r
61 \r
62 On Thu, Jan 19, 2012 at 22:53, Aaron Ecay <ecay@sas.upenn.edu> wrote:\r
63 > (let ((message-citation-line-format\r
64 >       (remove ?\n message-citation-line-format)))\r
65 >  ...)\r
66 >\r
67 > (Or, if you think someone might have a newline other than at the end of\r
68 > the string, you could do something a little more complicated to remove\r
69 > only a newline at the end.)\r
70 \r
71 I did something like this initially, to make the test pass, but my\r
72 thought is that some people might intend for that newline to be there\r
73 and we shouldn't be removing it.  Perhaps I'm being overly sensitive\r
74 to people with odd setups ;-).\r
75 \r
76 > Or you could introduce a new defcustom\r
77 > =91notmuch-message-citation-line-format=92 (with newline-less default), a=\r
78 nd\r
79 > let-bind m-l-c-f to that value.  But that is pretty ugly =96 we don=92t w=\r
80 ant\r
81 > to have to =93wrap=94 every variable whose default we don=92t like.\r
82 \r
83 Agreed, not a good solution.\r
84 \r
85 > I=92m personally of the opinion that notmuch should just say =93the mail\r
86 > composition facility is provided by message mode (here is the\r
87 > documentation on customizing it)=94.  Message mode is 8,000 lines of\r
88 > elisp.  We have the choice to:\r
89 > - write our own message composition mode\r
90 > - wrap (as explained above) the default message-mode variables we don=92t\r
91 >  like in notmuch-prefixed variants, with suitable let-bindings.\r
92 > - use only the parts of message-mode that we like\r
93 > - pass composition off to message mode\r
94 >\r
95 > The first option just doesn=92t make sense.  The second is also a little\r
96 > nuts.  The third is what we are trying now, but it=92s painful =96 the\r
97 > message mode code has its own structure and its own defaults, which\r
98 > don=92t always agree with notmuch=92s.  I am in favor of the fourth =96\r
99 > notmuch=92s elisp code should pass data to message mode in the most low\r
100 > level form it can, and let message mode do any extra work in the way\r
101 > it already does.  And users should customize message composition via\r
102 > message mode, not notmuch.  There=92s a tradeoff to this approach =96 by\r
103 > controlling more within notmuch, we can have nicer defaults at the\r
104 > expense of more brittle code and/or fewer user-visible customizations.\r
105 >\r
106 > This is not in any way a criticism of your work (which is great) =96\r
107 > you=92re right that you need =93permission=94 to uproot the defaults, and=\r
108  I=92m\r
109 > advocating for it to be given.\r
110 \r
111 I think we're on the same page here - I definitely prefer to have\r
112 notmuch-mua use existing emacs functionality wherever it makes sense.\r
113 The only question in my mind is how ugly we're willing to let the\r
114 defaults be in order to leverage existing stuff.\r
115 \r
116 > One possible step that might ease the transition pain could be for\r
117 > notmuch=92s emacs interface to have a configuration file (similar to\r
118 > Wanderlust=92s ~/.wl; I believe Gnus also uses a ~/.gnus).  The idea is\r
119 > that this file contains elisp code, and is loaded by notmuch the first\r
120 > time any notmuch-related commands are invoked by the user.  If the file\r
121 > does not exist, notmuch could create it with default content that sets\r
122 > message-citation-function, message-citation-line-format,\r
123 > message-yank-prefix (to get rid of the ugly default whereby message-mode\r
124 > indents the original message by four spaces instead of inserting =93> =94=\r
125 ),\r
126 > etc.  If there is interest in this approach, I=92d be happy to work on a\r
127 > patch for it.\r
128 \r
129 This would be a good way to get around the ugly defaults problem, and\r
130 it would also be an easy way for people to share their notmuch/emacs\r
131 setups.  I already have my setup in a file separate from my normal\r
132 emacs config, and I run `emacs -q -l ~/.emacs-notmuch -f notmuch` so\r
133 it doesn't load my normal, programming-oriented setup.\r
134 \r
135 One additional issue I noticed this morning with using\r
136 message-cite-original: it doesn't wrap/fill the quoted message.  I'm\r
137 guessing there's a way to make message-cite-original do this, but I\r
138 haven't figured it out.\r