Comment 4 for bug 695418

    Uday> - The vm-auto-displayed-mime-content-types problem should have blocked
    Uday> the multipart message from being displayed properly as well. Was that
    Uday> the case?

No, well, the message was not decoded, so I saw raw MIME code and had
to hit D. But that I didn't mind.

    Uday> - You say that it works fine in 8.0.9. Does it mean that "mutipart"
    Uday> didn't need to be included in vm-auto-displayed-mime-content-types in
    Uday> that version? The NEWS file doesn't say that there has been a change
    Uday> to this policy either.

I guess my seeing raw MIME was a consequence of the missing "multipart".

    Uday> - Intuitively, it seems to me that "multipart" types should be handled
    Uday> automatically and shouldn't be controllable from the
    Uday> auto-displayed... variable. Do you agree?

Partially--as long as I can distinguish between multipart/mixed and
multipart/alternative (I've "(setq vm-mime-alternative-select-method 'all)").

    Uday> Secondly, it seems to me that vm-reply-include-text shouldn't depend
    Uday> on the auto-displayed... variable either. I will look into this.

If I understand the code correctly, vm-yank-message invokes
vm-yank-message-mime when vm-reply-include-text is nil, and here the
auto-display variables kick in; only the alternative select method is
forced to be 'best-internal.

Guten Rutsch,
happy New Year,

Wilhelm

--

"Do you think what we're doing is wrong?"
"Of course it's wrong! It's illegal!"
"I've never done anything illegal before."
"I thought you said you were an accountant!"

--

 **************************************** fixed pitch fonts! **
  Wilhelm Müller Herbststraße 66
  D-28215 Bremen Germany (o_
  <email address hidden> +49-(0)421-169 2525 (o_ (o_ //\
  1024D/2048g 5E6E CF83 B15E C7ED 1A31 (/)_ (/)_ V_/_
   F9435BF6 E9F3 F509 FD7B F943 5BF6 © N.Smith