Re: RMAIL, MIME-related bug

[Stefan Monnier]

>> Of course, you also need to keep the signed-text unless you're
>> super-extra-careful to make sure that you can re-create the exact same
>> byte-sequence from the rest of the data, which is rather unlikely.

> OK, let's keep the signed text un-changed, but I would prefer to do
> the decoding on normal messages. As Eli points out, this is logical
> to do once on message arrival.

I see nothing logical about it.  AFAICT, the message will be saved somehow
in a text file, so you'll need to use some kind of unambiguous textual
representation of the various parts of the message.  Of course, you can
re-invent the wheel or use another existing wheel (the builtin lisp
printer), but using the original MIME representation is a pretty
natural choice.

>> Why do people even consider doing any processing at that point?
> Just to optimise the process. Doing it every time in show-message is
> even simplier from the programmer's point of view.

I'd first concentrate on getting something working correctly.
Especially since there is no evidence that performance will be a problem,
let alone that a pre-processed form will be more efficient.

> You are right, but let's focus on the need not to invent the
> RMAIL-MIME, no additional header in between the message. Do you agree
> that hiding header fields is preferred to having two message headers?

I don't really know the details of what this is referring to.
I generally like approaches based on adding text-properties and overlays
rather than modifying buffer text, but modifying buffer text can be much
simpler, with fewer surprises and much more flexible (I like my headers to
be sorted for example, which can't be done just by hiding undesirable
header fields).


        Stefan