[PATCH v2] emacs: Improve the cited message included in replies

[David Edmondson]

On Sat, May 10 2014, Mark Walters wrote:
> On Thu, 08 May 2014, David Edmondson <dme at 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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 310 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140512/72ec7942/attachment-0001.pgp>