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

[Stephen J. Turnbull]

>>>>> "rms" == Richard Stallman <address@hidden> writes:

    rms> It pretty much has to be an Emacs buffer, or part of one.
    rms> There is no other natural or easy way to implement it in the
    rms> context of Emacs.  The question would be, is it a separate
    rms> buffer, or a part of another buffer, or what?

If you want to preserve the original contents of the buffer, you must
copy them somewhere, because many of the transformations performed to
make text displayable are not invertible.  For example, it is
perfectly legal in ISO 2022 coding systems to have two charset
designations with no intervening text.  The first one will get lost.
Messages from older MUAs may contain the so-called abbreviated escape
sequences for Japanese and Chinese; a modern one would write them out
in the longer form.  It is almost always possible to unify ISO 8859/1
and ISO 8859/15 to ISO 8859/15, yet with cut and paste under current
situation, Emacs will produce a buffer with multiple charsets.
However, Emacs may or may not attempt to unify those charsets on
write, depending, I believe, on user options.

Quoted-printable, division of MIME encoded-words, and so on all
present similar issues.

Of course all of these could be handled by setting a text property
saying "in the original this was ISO 8859/1 but it has been unified to
ISO 8859/2" or putting an invisible property on a redundant escape
sequence and leaving it in the buffer, but that's ugly and
fault-prone.

    rms> In Rmail currently it is possible to type e and edit a
    rms> message.  Right now we do this through editing the buffer of
    rms> the RMAIL file.  With better MIME support, this may have to
    rms> be implemented differently, but I hope we can keep it working
    rms> somehow.

I think this will require a lot of work if you wish to preserve file
text verbatim unless explicitly edited (and this is essential for
signed messages, for example).

    rms> If we copy the message into another buffer for viewing, that
    rms> tends to lead to complications of the situation, because
    rms> there are multiple buffers instead of just one.  We could try
    rms> adding features to hide that, or we could expose it and not
    rms> hide anything.

I don't see how it gets complicated.  You put a couple of markers in
the original buffer, copy the region to the presentation buffer, and
transform it.  If you don't edit it, (erase-buffer) and go on to the
next message.  If you want to edit, you edit the presentation buffer,
in exactly the same way that currently you would edit the Rmail
buffer.  Once you've changed the presentation buffer, I see no reason
not to unify charsets, remove redundant escape sequences, and so on.
Once you're done, you simply replace the marked region in the original
buffer.  Reversion is simple: you refresh from the original buffer, no
messing with undo etc.  In this model, the only operations you perform
on the original buffer are (1) visible header movement, (2) setting
flags in Rmail-specific headers, and (3) replacement of the whole
message with an edited version.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
Universi