Re: Rmail changes for Emacs 22

[Eli Zaretskii]

> Date: Wed, 23 Oct 2002 05:57:07 -0400
> From: Paul Michael Reilly <address@hidden>
> 
> I'm not sure that it is totally obvious, but AFAICS there are TWO
> distinct coding system issues.  First is the message based decoding
> that everyone seems to recognize that is necessary to view messages.
> Second is the coding system used for mail file/buffer.  They are
> mostly orthogonal.

??? It is customary in Emacs that after decoding text we set the
buffer's file coding system to what was used to decode the text.
That's what RMAIL does today when it decodes and displays a message:
the (narrowed) buffer's buffer-file-coding-system is set to the
coding system used to decode the message.

So, unless I grossly misunderstand what you wanted to say, the two
issues you mentioned are not at all orthogonal, they are more like one
and the same.

> The mail buffer coding system will be dynamic.  It should mostly be
> iso-latin1 according to mail rfcs but Users will tend to abuse the
> specs so Rmail needs to be robust enough to handle that abuse.  How
> exactly remains to be decided.

Why not use what RMAIL does today: it looks at the charset= header,
and if that's absent, guesses using the user settings, the defaults,
and the encoding-detection routines (in that order)?

> Editing of messages opens up a huge can of worms wrt coding system.
> If anyone can state a sensible and effective policy for dealing with
> coding system conflicts while editing messages, more power to 'em.

Assuming normal usage, I don't see why we should deviate from the
normal policy used for saving buffers to disk files.  Emacs already
has machinery to deal with mixed charsets in a buffer, including
prompting the user for choosing the encoding if Emacs unable to
decide.

In general, as I've said elsewhere in this thread, I think Emacs
should encode each message in its original encoding (given by
charset=).  There are some exceptions to that rule (which I also
mentioned), but I'd suggest first to agree on the rule.

> It is easy to foresee Users changing message headers
> and bodies in ways that would render a message unmailable and/or
> unviewable in another mail agent but are nevertheless doable within
> Emacs.

Emacs gives you enough rope to hang yourself.  I won't worry too much
about those who do.