1 Return-Path: <markwalters1009@gmail.com>
\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 4A4C7431FC0
\r
6 for <notmuch@notmuchmail.org>; Mon, 12 May 2014 01:11:19 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=0.201 tagged_above=-999 required=5
\r
12 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
\r
13 FREEMAIL_ENVFROM_END_DIGIT=1, FREEMAIL_FROM=0.001,
\r
14 RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled
\r
15 Received: from olra.theworths.org ([127.0.0.1])
\r
16 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
17 with ESMTP id 56xUSlTY0z81 for <notmuch@notmuchmail.org>;
\r
18 Mon, 12 May 2014 01:11:13 -0700 (PDT)
\r
19 Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com
\r
20 [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
\r
21 (No client certificate requested)
\r
22 by olra.theworths.org (Postfix) with ESMTPS id 5CF54431FBF
\r
23 for <notmuch@notmuchmail.org>; Mon, 12 May 2014 01:11:13 -0700 (PDT)
\r
24 Received: by mail-wi0-f176.google.com with SMTP id n15so4004984wiw.3
\r
25 for <notmuch@notmuchmail.org>; Mon, 12 May 2014 01:11:12 -0700 (PDT)
\r
26 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
\r
27 h=from:to:subject:in-reply-to:references:user-agent:date:message-id
\r
28 :mime-version:content-type;
\r
29 bh=ycS+rkS1OWHXfrNz2JIn6iFOEOgn6QO7oEE1MIcIcVw=;
\r
30 b=EiQidQSqZFSQYQ/DvFaHYF7ZuqIM+7X7ht6yEuoXRdOG9+61PSh/PcrXGCFDJRMUgq
\r
31 2JhFjkvynyT8zB8C1J9Evqj05EuQlU9HaA3V+L0OooESobyBf19UrB6wg66REqwQfdIw
\r
32 FXt3LCKnqf9YHGXfzF+B8SF5sXDknLaZ7TskbyqxGxGnZCuJJaoQHDVDS8AR0bF9QxuH
\r
33 zK5mrdGUYN6tOyCcaMGwVWazcaDtLBE6McIjBGiPDewZ4nuZKwnlfIGRzVeyGbQeRXhS
\r
34 lWIQO/2nQjzuDgbDlihnTR9s7c5ioNsknLUasRL+/wY+pcolHFbZ+OmedTHV0rbGVXOu
\r
36 X-Received: by 10.194.122.6 with SMTP id lo6mr20077133wjb.38.1399882272255;
\r
37 Mon, 12 May 2014 01:11:12 -0700 (PDT)
\r
38 Received: from localhost (5751dfa2.skybroadband.com. [87.81.223.162])
\r
39 by mx.google.com with ESMTPSA id c7sm16890357wjf.19.2014.05.12.01.11.11
\r
40 for <multiple recipients>
\r
41 (version=TLSv1.2 cipher=RC4-SHA bits=128/128);
\r
42 Mon, 12 May 2014 01:11:11 -0700 (PDT)
\r
43 From: Mark Walters <markwalters1009@gmail.com>
\r
44 To: David Edmondson <dme@dme.org>, notmuch@notmuchmail.org
\r
45 Subject: Re: [PATCH v2] emacs: Improve the cited message included in replies
\r
46 In-Reply-To: <cunzjinbkfr.fsf@hotblack-desiato.hh.sledj.net>
\r
47 References: <1399482846-25308-1-git-send-email-dme@dme.org>
\r
48 <1399530272-11857-1-git-send-email-dme@dme.org>
\r
49 <87ha4y8286.fsf@qmul.ac.uk>
\r
50 <cunzjinbkfr.fsf@hotblack-desiato.hh.sledj.net>
\r
51 User-Agent: Notmuch/0.15.2+615~g78e3a93 (http://notmuchmail.org) Emacs/23.4.1
\r
52 (x86_64-pc-linux-gnu)
\r
53 Date: Mon, 12 May 2014 09:11:10 +0100
\r
54 Message-ID: <87mwenzaap.fsf@qmul.ac.uk>
\r
56 Content-Type: text/plain; charset=us-ascii
\r
57 X-BeenThere: notmuch@notmuchmail.org
\r
58 X-Mailman-Version: 2.1.13
\r
60 List-Id: "Use and development of the notmuch mail system."
\r
61 <notmuch.notmuchmail.org>
\r
62 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
63 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
64 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
65 List-Post: <mailto:notmuch@notmuchmail.org>
\r
66 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
67 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
68 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
69 X-List-Received-Date: Mon, 12 May 2014 08:11:19 -0000
\r
71 On Mon, 12 May 2014, David Edmondson <dme@dme.org> wrote:
\r
72 > On Sat, May 10 2014, Mark Walters wrote:
\r
73 >> On Thu, 08 May 2014, David Edmondson <dme@dme.org> wrote:
\r
74 >>> emacs: Improve the cited message included in replies
\r
77 >>> - Don't run the text/plain hooks when generating the message to quote.
\r
80 >> In principle I like this approach: keeping show and reply closely linked
\r
83 >> At the moment, as you say, the tests don't all pass. The first reason is
\r
84 >> that this puts in buttons for the parts. Stopping that happening is not
\r
85 >> completely trivial as we need to make sure that the instruction gets
\r
86 >> passed down to sub-parts of multiparts etc. (You could argue that the
\r
87 >> 'no-button option to notmuch-show-insert-bodypart is buggy as it only
\r
88 >> stops the top level button for the part)
\r
90 > That seems straightforward. I was sure that there was a variable listing
\r
91 > part types that didn't require buttons (which could be let-bound), but I
\r
92 > must have been imagining it.
\r
94 > Inserting the button text for the trivial case (single text/plain part)
\r
95 > is already special-cased in the show code. In the case where only a
\r
96 > single part is being shown (e.g. multipart/alternative with text/plain
\r
97 > and text/html with the text/html hidden) it would make sense _not_ to
\r
98 > show the button text. For more complex messages (e.g. multipart/mixed
\r
99 > with text/plain and message/rfc822, where the message/rfc822 contains
\r
100 > multiple parts), showing the button text seems useful to allow the
\r
101 > different sub-sections of the reply to be distinguished.
\r
103 Yes that is true: I hadn't thought of that.
\r
105 > Perhaps there is an approach based on the complexity of the quoted
\r
106 > message that should determine whether the button text is inserted (which
\r
107 > might also apply (in modified form?) in normal message display)? Normal
\r
108 > message display has to allow for some interaction with the parts
\r
109 > (show/hide, etc.), which doesn't apply to citation.
\r
111 >> Secondly, the existing code only includes text sub-parts of the
\r
112 >> message. I would think your version might include any sub-parts show is
\r
113 >> configured to display, including, say images. (However, in my testing
\r
114 >> images didn't seem to be included: I am not sure why.)
\r
118 I phrased this badly. I don't want images included: I just couldn't see
\r
119 why they weren't with your current patch (as they are displayed in show
\r
123 > Inserting the images in the reply buffer itself would not be
\r
124 > difficult. What should happen when the user hits 'send'? We currently
\r
125 > don't have a composition mode that would allow us to generate useful
\r
126 > output in that case. Adding one feels like a lot of work. In many cases
\r
127 > it would be necessary to transform the message into HTML to properly
\r
128 > represent the content.
\r
130 > MML (the markup used in `message-mode') is really not designed for
\r
131 > something this complex.
\r
133 >> I can't tell how much work it is to modify show to take account of these
\r
134 >> things, so am not sure if this is the best approach, or just adding
\r
135 >> something to deal with rfc822 to our existing reply code is easier.
\r
137 > The approach in this patch mostly involves removing code - adding
\r
138 > special case code to notmuch-mua.el to support message/rfc822 involves
\r
139 > _adding_ a bunch more complex code (I tried that first).
\r
141 I guess my concern with adding to the show code is that is already more
\r
142 complicated than I would like (invisibility, hidden parts, lazy parts
\r
143 etc). But I am very definitely interested in seeing what a more finished
\r
144 version of your patch would look like.
\r