p0.88 misparses 2nd-level message forwarding

p0.88 misparses 2nd-level message forwarding

[Karl Kleinpaste]

1. Send yourself a test message -- normal message, text/plain.
2. Forward that message to yourself -- an inline message/rfc822.
3. Forward *that* message to yourself.
You now have an inline message/rfc822 containing another inline
message/rfc822.

p0.88's display of this will be...confused.

Assuming that you prefix each forwarding with a bit of text/plain as
well, you will see:

        [1. text/plain]
        containing the "outermost" (3rd level) new text.

        [2. message/rfc822]
        containing nothing but (in my case) an X-Sent: header (which BTW
        erroneously duplicates the topmost X-Sent; I sent a bug report
        about this last week).

        [3. text/plain]
        containing the 2nd level text which prefaced the original message
        on 1st forwarding...  *followed by* the entire remaining message
        displayed as text/plain, including both the 2nd level and 1st
        level messages...  all as part of a single "3." section.

        [4. message/rfc822]
        containing the original, 1st level forwarded message.

Note that the innermost, original text is duplicated in both the
3. and 4. sections.

Perhaps significantly, the buttonized (`K b') display of these
sections will show the button areas as
        [1. text/plain] in *bold*
        [2. message/rfc822] in *bold*
        [3. text/plain] in /italic/
        [4. message/rfc822] in *bold*
Shouldn't these be labelled something hierarchical anyway, such as 1., 
2., 2.1, 2.2, 2.2.1?

Something Truly Evil happened to MIME interpretation recently...

--karl

Re: p0.88 misparses 2nd-level message forwarding

[Shenghuo ZHU]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

>>>>> "KK" == Karl Kleinpaste <karl@justresearch.com> writes:

KK> 1. Send yourself a test message -- normal message, text/plain.
KK> 2. Forward that message to yourself -- an inline message/rfc822.
KK> 3. Forward *that* message to yourself.
KK> You now have an inline message/rfc822 containing another inline
KK> message/rfc822.

KK> p0.88's display of this will be...confused.

KK> Assuming that you prefix each forwarding with a bit of text/plain as
KK> well, you will see:

KK>         [1. text/plain]
KK>         containing the "outermost" (3rd level) new text.

KK>         [2. message/rfc822]
KK>         containing nothing but (in my case) an X-Sent: header (which BTW
KK>         erroneously duplicates the topmost X-Sent; I sent a bug report
KK>         about this last week).

KK>         [3. text/plain]
KK>         containing the 2nd level text which prefaced the original message
KK>         on 1st forwarding...  *followed by* the entire remaining message
KK>         displayed as text/plain, including both the 2nd level and 1st
KK>         level messages...  all as part of a single "3." section.

KK>         [4. message/rfc822]
KK>         containing the original, 1st level forwarded message.

KK> Note that the innermost, original text is duplicated in both the
KK> 3. and 4. sections.

Try this patch.

1999-06-22  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* mm-view.el (mm-inline-message): Fix message view bug.
	* gnus-art.el (gnus-article-prepare): Ditto.


[-- Attachment #2: 88-zsh8.diff --]
[-- Type: application/x-patch, Size: 1379 bytes --]

[-- Attachment #3: Type: text/plain, Size: 483 bytes --]


KK> Perhaps significantly, the buttonized (`K b') display of these
KK> sections will show the button areas as
KK>         [1. text/plain] in *bold*
KK>         [2. message/rfc822] in *bold*
KK>         [3. text/plain] in /italic/
KK>         [4. message/rfc822] in *bold*
KK> Shouldn't these be labelled something hierarchical anyway, such as 1., 
KK> 2., 2.1, 2.2, 2.2.1?

It is difficult. The label is used as the argument of
gnus-article-view-part (press 'b').

-- 
Shenghuo ZHU

Re: p0.88 misparses 2nd-level message forwarding

[Karl Kleinpaste]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:
> Try this patch.
> 	* mm-view.el (mm-inline-message): Fix message view bug.
> 	* gnus-art.el (gnus-article-prepare): Ditto.

Fabulous.  Many thanx, that fixed the situation perfectly.  Lars, that 
one needs to get into p0.89.

> It is difficult. The label is used as the argument of
> gnus-article-view-part (press 'b').

Interesting point.  So the conclusion is simply to number them
sequentially?  That works fine for me, but I thought we were up
against some sort of MIME RFC requirement to force a hierarchical view 
somehow.

--karl

Re: p0.88 misparses 2nd-level message forwarding

[Lars Magne Ingebrigtsen]

Karl Kleinpaste <karl@justresearch.com> writes:

> Interesting point.  So the conclusion is simply to number them
> sequentially?

That's what seems to make the most sense in an Emacs context.

> That works fine for me, but I thought we were up against some sort
> of MIME RFC requirement to force a hierarchical view somehow.

I don't think the RFCs say anything about that...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen