Re: Different (buffer-file-)coding-systems for different regions of one buffer? (for Rmail MIME)

["Stephen J. Turnbull" <stephen@xemacs.org>]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

    rms> I have the impression we are not talking about the same
    rms> thing.

Perhaps not.  The thread started with a proposal for a coding system
that would present Rmail with an already decoded buffer, so that the
process of dealing with multiple coding systems and the like would be
transparent to Rmail.  And I've been assuming that.

But the basic idea applies (although with somewhat less force) to any
one-buffer implementation.  If decoding and encoding are not inverses,
you risk corruption simply by reading mail.

    That's assuming that it is text.  This implementation
    would make corruption of attached binaries likely and signed
    messages somewhat likely

    rms> I don't think so.  Why would you edit a binary attachment?

application/x-patch, for example.  From the point of view of the user
it's text to be read, but patch will get upset if you cause any change
to the original context lines.  I've been bit by that one a number of
times when a program decided to reencode a patch to Japanese text with
a variant of ISO-2022-JP different from the original.  Patch won't
apply, with no visible sign of why not.  Grrr!  GPG-signed, for
another example.

You don't need to explicitly edit one of these attachments, just
(non-invertibly) decode it for viewing and reencode it for saving the
buffer.

It just occurred to me that you must use a presentation buffer, or
save the entire encrypted text, for a GPG _encrypted_ message, since
you can't reencode that.  Of course that's a solitary special case.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.