11:05 a.m.
In article <871w4bmc3o.fsf(a)uwakimon.sk.tsukuba.ac.jp> "Stephen J.
Turnbull" <stephen(a)xemacs.org> writes:
Given a MIME message with content-type
multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"
and this structure
multipart/mixed
text/plain, charset=us-ascii
text/x-patch, charset=us-ascii, content-disposition=inline
text/plain, charset=us-ascii
application/pgp-signature
`vm-reply-include-text' and `vm-followup-include-text' parse it
incorrectly. They leave you in a buffer with only the first
text/plain part included and quoted. The second text/plain part
should definitely be included and quoted, and I would argue that the
text/x-patch part should be included and quoted because it has
content-disposition "inline", so the author expected it to be
displayable.
I don't think this is a bug - you just don't agree with the spec.
MIME doesn't have a notion of include-and-quote, so if you want to include
a multipart message you have to include it as a MIME part. It's not obvious
what the right answer is to how to include-and-quote such a message.
Kyle (presumably) took the easiest option, which is to assume the
first text part is the message - which usually works.
An alternative view, which is what you appear to want here, is that
you should include-and-quote the text seen when you view the message.
If that's what you want, VM will do it for you - see
vm-reply-include-presentation .
I find that sometimes I want one, sometimes the other, so I have the
following little mod in my .vm:
; mods to R and F so that they include the presentation buffer
; if called with C-u.
(require 'vm-reply)
(defun vm-reply-include-text (count)
"Reply to the sender (only) of the current message and include text
from the message. See the documentation for function vm-reply for details.
Modified to include presentation buffer if given C-u prefix argument."
(interactive "P")
(vm-follow-summary-cursor)
(vm-select-folder-buffer)
(vm-check-for-killed-summary)
(vm-error-if-folder-empty)
(let ((c 1)
(vm-reply-include-presentation vm-reply-include-presentation))
(if (consp count)
(setq vm-reply-include-presentation t)
(setq c (prefix-numeric-value count)))
(vm-do-reply nil t c)))
(defun vm-followup-include-text (count)
"Reply to all recipients of the current message and include text from
the message. See the documentation for the function vm-reply for details.
Modified to include presentation buffer if given C-u prefix argument."
(interactive "P")
(vm-follow-summary-cursor)
(vm-select-folder-buffer)
(vm-check-for-killed-summary)
(vm-error-if-folder-empty)
(let ((c 1)
(vm-reply-include-presentation vm-reply-include-presentation))
(if (consp count)
(setq vm-reply-include-presentation t)
(setq c (prefix-numeric-value count)))
(vm-do-reply t t c)))
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
midnight
New subject: VM-BUG: vm-followup-include-text parses multipart message wrong
Julian Bradfield writes:
I don't think this is a bug - you just don't agree with the
spec.
Which spec? The docstring says "include text from the message", and
while that could be interpreted to mean "randomly selected bits",
normal practice is to include all of it. If the spec is really this
cheesy, it should say so explicitly. But I can't imagine Kyle would
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. :-)
I also seem to recall that VM DTRTs when handed a multipart message
with different parts containing different charsets.
MIME doesn't have a notion of include-and-quote,
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.
An alternative view, which is what you appear to want here, is that
you should include-and-quote the text seen when you view the message.
If that's what you want, VM will do it for you - see
vm-reply-include-presentation .
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.
At the very least the documentation of these functions needs to be
improved. In particular, -include-presentation forms need to say what
happens to those non-text objects that do end up getting displayed.
Do they get included as MIME parts containing the multimedia objects
they represent?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:14 a.m.
New subject: VM-BUG: vm-followup-include-text parses multipart message wrong
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.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:31 a.m.
New subject: VM-BUG: vm-followup-include-text parses multipart message wrong
Julian Bradfield writes:
stephen writes:
>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?
When they go back on the wire, of course. However, in the MUAs I use
alone there are two different non-MIME methods: VM uses an elegant
extent-as-button-with-properties to specify it while Gnus uses a grody
*ML-ish mishmash.
However, the interpretation I had in mind was to flatten all the text
parts into a single quoted slab of text. This violates the MIME
structure, of course, and that's what I mean by "the MUA can do what
it wants to".
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.
I don't deny it's useful to do stuff with the presentation; I just
think that -include-text should try harder to get all the text. If
it's non-trivial to do that, then the MIME parser needs to be
rewritten IMO.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:44 a.m.
New subject: VM-BUG: vm-followup-include-text parses multipart message wrong
In article <871w4bmc3o.fsf(a)uwakimon.sk.tsukuba.ac.jp>
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>multipart/mixed
> text/plain, charset=us-ascii
> text/x-patch, charset=us-ascii, content-disposition=inline
> text/plain, charset=us-ascii
>application/pgp-signature
>
>`vm-reply-include-text' and `vm-followup-include-text' parse it
>incorrectly. They leave you in a buffer with only the first
>text/plain part included and quoted. The second text/plain part
>should definitely be included and quoted, and I would argue that the
>text/x-patch part should be included and quoted because it has
>content-disposition "inline", so the author expected it to be
>displayable.
FWIW, Gnus quotes all parts for an article with this structure:
<* mixed>
<1 text>
<2 x-patch> (inline)
<3 text>
BTW, there's neither a In-Reply-To nor a References header in Julian's
article. A VM bug?
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6039
days inactive
6040
days old
4 comments
3 participants
participants (3)
-
Julian Bradfield -
Reiner Steib -
Stephen J. Turnbull