Received-SPF: pass (google.com: domain of awg@xvx.ca designates 10.152.102.237
	as permitted sender) client-ip=10.152.102.237; 
MIME-Version: 1.0
Sender: awg@xvx.ca
In-Reply-To: <20120217200017.GG5991@mit.edu>
References: <1329361957-28493-1-git-send-email-awg+notmuch@xvx.ca>
	<1329361957-28493-8-git-send-email-awg+notmuch@xvx.ca>
	<20120217200017.GG5991@mit.edu>
Date: Tue, 21 Feb 2012 23:46:12 -0700
Message-ID:
 <CAMoJFUszH+RjfOj2qpFL6ZYpG418ZtW9za56pzD7gxhp70BJFw@mail.gmail.com>
Subject: Re: [PATCH v5.2 7/7] emacs: Use the new JSON reply format and
	message-cite-original
From: Adam Wolfe Gordon <awg+notmuch@xvx.ca>
To: Austin Clements <amdragon@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: notmuch@notmuchmail.org
Precedence: list

Hi Austin,

A couple of quick notes below, just before I send the new version:

On Fri, Feb 17, 2012 at 13:00, Austin Clements <amdragon@mit.edu> wrote:
> One of the biggest wins of using consistent JSON parsing settings is
> that this can be replaced with notmuch-show-mm-display-part-inline,
> which, as far as I can tell, accomplishes the same thing, but handles
> a lot of corner-cases that this doesn't (like crypto and charset
> conversion).

This would be very desirable indeed, but after taking a stab at it,
I've discovered it's a really significant amount of work. The show
code relies on a bunch of buffer-local variables regarding crypto and
such, which are tricky to factor out into notmuch-lib.

Do you think it's acceptable to leave this as future work?

> Alternatively, notmuch-mua-get-quotable-parts could be
> notmuch-mua-insert-quotable-parts, which would probably simplify
> things a bit. =A0Your call.

I've decided to leave this as get-quotable-parts. This is mostly my
personal preference to have a single function do the insertions when
possible, which I think makes the flow more obvious.

> Is message-cite-original guaranteed to leave point in a reasonable
> place for this or should we create our own marker above (probably
> after the if re-search-backward..) and use it here to get point to the
> right place?

It turns out it actually wasn't, which is why MML tags weren't getting
escaped twice. I've fixed this.