On Mon, 12 May 2014, David Edmondson <dme at dme.org> wrote: > 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.
Yes that is true: I hadn't thought of that. > 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. I phrased this badly. I don't want images included: I just couldn't see why they weren't with your current patch (as they are displayed in show mode) > > 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). I guess my concern with adding to the show code is that is already more complicated than I would like (invisibility, hidden parts, lazy parts etc). But I am very definitely interested in seeing what a more finished version of your patch would look like. Best wishes Mark
