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

[Stephen J. Turnbull]

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

        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.

    rms> It is important to have a way to edit the text that is
    rms> displayed.  It is desirable but not very important to
    rms> preserve the first charset designation.

That's assuming that it is text.  This implementation would make
corruption of attached binaries likely and signed messages somewhat
likely (I haven't done a survey to see how many redundant designations
are in my text mail files in about 6 years, but in 1997 there were a
fair number; about 1 every 20 Japanese messages).

    rms> If we can't do both, we should do the former.

I don't see why editing the presentation buffer, then replacing the
region in the full buffer, doesn't satisfy this requirement.

    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> This is easy to do--just don't replace the original text
    rms> unless the user has edited the message.

But you don't have the original text any more (except in the disk
file).  You have decoded text in the buffer.  When you save that, you
will lose redundant ISO 2022 designations and directional sequences,
you will lose "naked newlines" in DOS files.  You will likely lose the
exactly format of decoded MIME words in headers in embedded messages.

And remember, if you implement this as an "rmail-coding-system", _all_
messages in the buffer will be automatically decoded.  It is not just
the current message whose corruption is being risked.

    rms> The user must type an explicit command, currently e, to edit
    rms> the message.  The edited text would be stored back into the
    rms> file only when the user exits edit mode (and not if he aborts
    rms> the edit).

If you change the displayed buffer at all (eg, to set a READ flag),
you save the decoded buffer contents.  These are in general different
at the binary level from what is on disk, and must be encoded.  ISO
2022 and MIME do not guarantee that decoding is invertible, and in
fact often the originating and receiving functions are different
implementations, and are not inverses.

        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.

    rms> Right now, if I switch to buffer RMAIL, I see the message
    rms> that is selected in the buffer RMAIL.  If that message is
    rms> actually displayed in another buffer, then switching to RMAIL
    rms> won't show it, or won't show it properly.

Kai Großjohann's answer to this (rename the presentation buffer to
RMAIL, users rarely will want to see the full buffer, so it can be
renamed to a "hidden" buffer name) is correct as far as I can tell
from my own experience, convenient for the user, and easily
implemented.  It's even convenient for third-party developers who
provide add-on facilities, as they don't need to worry so much about
buffer restrictions as under Rmail.  I used to find that a major
annoyance (admittedly, I was a rather unskilled Lisp programmer when I
was using Rmail).

You are right that this is a potential problem.  Both VM and Gnus try
to maintain "window configurations", and they occasionally get it
wrong.  It's easy to work around, but annoying when it happens.
However, their window configurations are much more complex than the
scheme Kai suggested, and I think the probability of it causing
problems is very low.

AFAIK Rmail is the only remaining major Emacs MUA that handles mail
folders implemented as single files by transforming to display format
in place in a single buffer.  In fact, IIRC VM switched from Rmail-
style "full-buffer-is-display-buffer" for text-only messages
relatively recently (it always had presentation buffers, but
restricted them to multimedia messages, eg, containing images or
audio).  While that's not in itself a good reason for Rmail to switch,
I think it tends to indicate that difficulty of implementation is not
so great as you think.


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