VM-BUG: vm-followup-include-text parses multipart message wrong

[Julian Bradfield]

>Which spec?  The docstring says "include text from the message", and

The spec is the code, of course ;-)
In this case, the code in vm-yank-message, which is sufficiently
complex that it would take me half an hour to understand fully, so
I'll leave it to Rob.

>say that the spec is to refuse to quote text unless it's in the first
>part.  I think he'd say it's a bug.  (He might refuse to fix it, Kyle
>being Kyle. :-)

Maybe... But I just want to jump in to let Rob know that not everybody
necessarily agrees with your interpretation!

>MIME isn't relevant here; it's a wire protocol.  What the MUA *does*
>is up to the MUA, MIME just tells it how to interpret what it gets off
>the wire.

Technically, yes - but realistically don't most MUAs use the structure
described by MIME to structure their messages?  I suppose there's some
awful ANSI X.nnn equivalent, but who uses it?

>I don't know what "include presentation" means, though.  I probably
>don't want the presentation if it includes audio or video, for
>example.  I probably do want it if it's a spam-by-jpeg.

What it actually means is: include the text of the presentation buffer
for the message. This is useful, because it means you can selectively
convert (e.g.) word attachments to text, and have them included in
your reply as text. 
That still leaves open your question:

>improved.  In particular, -include-presentation forms need to say what
>happens to those non-text objects that do end up getting displayed.

What happens with a MIME object displayed as a button, is that the
text description is included, but not the extent information that
makes the button. This is an interesting one.

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.