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>
