MIME-Version: 1.0
In-Reply-To: <m2r4z9irmp.fsf@gmail.com>
References: <1326009162-19524-1-git-send-email-awg+notmuch@xvx.ca>
	<m2r4z9irmp.fsf@gmail.com>
Date: Mon, 9 Jan 2012 18:53:30 -0700
Message-ID:
 <CAMoJFUupEQofCnqaaDLEaH+_QcO4b7hd-f8=HX8jJUCFke40Qw@mail.gmail.com>
Subject: Re: [PATCH 0/4] Quoting HTML-only emails in replies redux
From: Adam Wolfe Gordon <awg@xvx.ca>
To: Aaron Ecay <aaronecay@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: notmuch@notmuchmail.org
Precedence: list

Thanks for the suggestions.  Specific comments inline:

On Sun, Jan 8, 2012 at 18:36, Aaron Ecay <aaronecay@gmail.com> wrote:
>> There should probably be some customize variables for this in emacs, to =
control
>> (for example) whether to quote HTML parts and whether to prefer HTML or
>> plaintext parts for quoting. Any suggestions for what should be customiz=
able
>> would be appreciated.
>
> I think two variables should suffice: one (boolean) to control whether
> to quote standalone text/html parts, and one to control which parts of a
> multipart/alternative part to quote. =A0The latter should take possible
> values 'text, 'html, and 'both. =A0This requires the emacs reply
> functionality to distinguish between html parts that are part of a
> multipart/alternative and those which are not, which (AFAICT) the
> current code doesn=92t do.

The first one I think is obvious, and easy to add.  My previous
version actually had such an option, but I didn't bother with it this
time in the interest of getting the patch out.  I'll add this in and
send a new version.

Regarding the second suggestion, you're right that the current code
doesn't differentiate between text parts that are part of a
multipart/alternative and ones that aren't.  However, it does only
include parts with inline disposition, so it shouldn't end up quoting
stuff intended as attachments.  My thinking in the current operation
was to keep most of the complexity (i.e. going through the MIME parts
to pick out the relevant ones) in the C code, so that it doesn't have
to be implemented in each client - and also so I didn't have to
implement it in emacs lisp ;-).  Do you have some ideas for a JSON
format that's more complex than the current one (to include the
information necessary for making decisions about what to quote), but
less complex than something like notmuch show --format=3Djson (which
would require the client to descend the MIME tree completely to create
a reply)?

A third customization option I was thinking about is a way to control
the format of the first line of the body (On $date, $person wrote).  I
think it would be fairly simple to let people specify an arbitrary
format using any of the headers of the original message, so you would
set it to something like "On %date%, %from% wrote", or "Quoth %from%
(%date%)".  This might be particularly useful to users who correspond
normally in a language other than English.  Anyone have thoughts on
whether this is worth implementing?

> I haven=92t tested the patch yet, but it looks very promising. =A0Thanks!

Thanks for the suggestions - let me know if you have a chance to try it out=
.

--=20
Adam Wolfe Gordon