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

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

>>>>> "stktrc" == stktrc  <stktrc@yahoo.com> writes:

    stktrc> Because modifying the buffer means modifying the
    stktrc> underlying file (because Rmail writes the buffer back to
    stktrc> the file on exit for various reasons, message flags are
    stktrc> one I suppose).

This is why I originally switched to VM.  Rmail was unable to read,
and sometimes trashing[1], my mail files, which contained mixed
Japanese/ASCII/European encodings, and all of Unix/DOS/Macintosh
newline conventions.  We're not in Kansas anymore, Toto, and the Rmail
"narrow-to-message" model simply increases complexity dramatically
because of the underlying Mule model of coding-per-file.  (Which is
hard to see how you can avoid it.)

    stktrc> I'm not totally opposed to that approach.  It is an
    stktrc> alternative, but as stated before, I like the one folder -
    stktrc> one buffer concept for it's simplicity.

Fine.  This will go gangbusters if you set your spamassassin to throw
away all mail with "Content-Type" headers.  Now the world is simple
enough to fit into that concept well.

Otherwise, there are at least two radically different views of many
files, and there must be a buffer (in the generic sense of a separate
region of memory) for presentation, and one for the much more
restricted changes you wish propagated back to the file (setting
flags).  I see no good reason why the region of memory used for
presentation shouldn't "waste" a few score bytes and be promoted to an
Emacs buffer.

    stktrc> I thought there was a layer between the file system and
    stktrc> the Emacs buffer that decoded the bytes from the file into
    stktrc> characters that were inserted into the buffer (and the
    stktrc> other way when writing).  That is, the buffer would never
    stktrc> see the encoded data, it would just receive already
    stktrc> decoded characters in an Emacs internal representation.
    stktrc> If it had been like this,

It is like that in practice, most of the time.  But it's only
practical for simple cases, eg, where the whole file is encoded in one
encoding, or the whole file conforms to a fixed standard such as ISO
2022.  Multimedia (in the MIME sense) files can't work that way.  The
meta-information used to create the presentation is often a hint, or a
user option.

    stktrc> with the addition of the possibility of different
    stktrc> decodings for different parts, it could have been used for
    stktrc> the purposes described earlier (to display MIME messages
    stktrc> as if they had been decoded inline *without modifying* the
    stktrc> buffer).

But then how do you save the buffer (eg, if you have set flags)?  It
differs from the file, and the decoding process is not an isomorphism
(multimedia).


Footnotes: 
[1]  Many years ago.  And the trashed cases required a very special
configuration of very non-RFC-conformant messages.  Unfortunately,
these were quite common in Japan ca. 1994.  The Internet can be a very
hostile place!

-- 
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