Return-Path: <dme@dme.org>
X-Original-To: notmuch@notmuchmail.org
Delivered-To: notmuch@notmuchmail.org
Received: from localhost (localhost [127.0.0.1])
	by olra.theworths.org (Postfix) with ESMTP id 1EB29431FC0
	for <notmuch@notmuchmail.org>; Sun, 11 May 2014 23:06:18 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5
	tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled
Received: from olra.theworths.org ([127.0.0.1])
	by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id ViCgchGQY30Q for <notmuch@notmuchmail.org>;
	Sun, 11 May 2014 23:06:10 -0700 (PDT)
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com
 [74.125.82.47])	(using TLSv1 with cipher RC4-SHA (128/128 bits))	(No client
 certificate requested)	by olra.theworths.org (Postfix) with ESMTPS id
 15753431FBF	for <notmuch@notmuchmail.org>; Sun, 11 May 2014 23:06:09 -0700
 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id x12so6389415wgg.30
	for <notmuch@notmuchmail.org>; Sun, 11 May 2014 23:06:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:to:subject:in-reply-to:references:user-agent
	:from:date:message-id:mime-version:content-type;
	bh=xKgfVMpY/eCb2lVDCI5gICXdJKVtKQ9motlajydGzzA=;
	b=H3aC4QWbEvj7RFECdSSHaVMgzFvqy4bHBRLLvpgETjxrCVG/G20ii08QjC+uyse47J
	tn1v2w5LWx0+E35qA4tXgiqoDQY5QWo5sYiMF/TRGkM60K2G0usjL/yZBsvnjV/eKjMv
	kNFxPDzTH6uC5k4rAuK1fuKWvnRt6g6vOvKcYpQWJ46gPZQCeHp0poCn4d3XLAQxvj05
	eia0jPM5QC7JuHamsHsknruP83ZSvGgzWtaN+5sFBBVYFzJw0Y9P2fLZRB8LQKk+NQq3
	mVCPDli2DUPLOSYSJreOWuCGxIttFMgejnMf3TK2Zoa0JetZWqvECPNhwAdzYnQRXYJ/
	tbHg==
X-Gm-Message-State:
 ALoCoQmUoJ1u980KH9gqoU2UmyGeXJMntL96GTfAN1y+Cwcjor4TV3MqUzMgpAfGJpFsaG4WYNtm
X-Received: by 10.180.11.239 with SMTP id t15mr14066263wib.25.1399874768604;
	Sun, 11 May 2014 23:06:08 -0700 (PDT)
Received: from localhost ([2a01:348:1a2:1:a288:b4ff:fe8a:77d8])
	by mx.google.com with ESMTPSA id
	xm20sm14171402wib.19.2014.05.11.23.06.05 for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sun, 11 May 2014 23:06:06 -0700 (PDT)
To: Mark Walters <markwalters1009@gmail.com>, notmuch@notmuchmail.org
Subject: Re: [PATCH v2] emacs: Improve the cited message included in replies
In-Reply-To: <87ha4y8286.fsf@qmul.ac.uk>
References: <1399482846-25308-1-git-send-email-dme@dme.org>
	<1399530272-11857-1-git-send-email-dme@dme.org>
	<87ha4y8286.fsf@qmul.ac.uk>
User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.1
	(x86_64-pc-linux-gnu)
From: David Edmondson <dme@dme.org>
Date: Mon, 12 May 2014 07:06:00 +0100
Message-ID: <cunzjinbkfr.fsf@hotblack-desiato.hh.sledj.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
X-BeenThere: notmuch@notmuchmail.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: "Use and development of the notmuch mail system."
	<notmuch.notmuchmail.org>
List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
List-Archive: <http://notmuchmail.org/pipermail/notmuch>
List-Post: <mailto:notmuch@notmuchmail.org>
List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=subscribe>
X-List-Received-Date: Mon, 12 May 2014 06:06:18 -0000

--=-=-=
Content-Type: text/plain

On Sat, May 10 2014, Mark Walters wrote:
> On Thu, 08 May 2014, David Edmondson <dme@dme.org> wrote:
>> emacs: Improve the cited message included in replies
>>
>> v2:
>> - Don't run the text/plain hooks when generating the message to quote.
>>
>
> In principle I like this approach: keeping show and reply closely linked
> seems good.
>
> At the moment, as you say, the tests don't all pass. The first reason is
> that this puts in buttons for the parts. Stopping that happening is not
> completely trivial as we need to make sure that the instruction gets
> passed down to sub-parts of multiparts etc. (You could argue that the
> 'no-button option to notmuch-show-insert-bodypart is buggy as it only
> stops the top level button for the part)

That seems straightforward. I was sure that there was a variable listing
part types that didn't require buttons (which could be let-bound), but I
must have been imagining it.

Inserting the button text for the trivial case (single text/plain part)
is already special-cased in the show code. In the case where only a
single part is being shown (e.g. multipart/alternative with text/plain
and text/html with the text/html hidden) it would make sense _not_ to
show the button text. For more complex messages (e.g. multipart/mixed
with text/plain and message/rfc822, where the message/rfc822 contains
multiple parts), showing the button text seems useful to allow the
different sub-sections of the reply to be distinguished.

Perhaps there is an approach based on the complexity of the quoted
message that should determine whether the button text is inserted (which
might also apply (in modified form?) in normal message display)? Normal
message display has to allow for some interaction with the parts
(show/hide, etc.), which doesn't apply to citation.

> Secondly, the existing code only includes text sub-parts of the
> message. I would think your version might include any sub-parts show is
> configured to display, including, say images. (However, in my testing
> images didn't seem to be included: I am not sure why.)

Eek.

Inserting the images in the reply buffer itself would not be
difficult. What should happen when the user hits 'send'? We currently
don't have a composition mode that would allow us to generate useful
output in that case. Adding one feels like a lot of work. In many cases
it would be necessary to transform the message into HTML to properly
represent the content.

MML (the markup used in `message-mode') is really not designed for
something this complex.

> I can't tell how much work it is to modify show to take account of these
> things, so am not sure if this is the best approach, or just adding
> something to deal with rfc822 to our existing reply code is easier.

The approach in this patch mostly involves removing code - adding
special case code to notmuch-mua.el to support message/rfc822 involves
_adding_ a bunch more complex code (I tried that first).

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iKYEARECAGYFAlNwZMlfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldDc1M0Y5NDJDMEExNjc3MDE4OURGMUYyMDY5
RUNEMEFCRjA0OTY1MTYACgkQaezQq/BJZRbo+wCeOQqTZtDN557pZ5U2mMiIB+ce
zJUAnRlQ9BRdK92ajo525yIp3QPOwxxI
=Kvgj
-----END PGP SIGNATURE-----
--=-=-=--