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

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

>>>>> "Eli" == Eli Zaretskii <eliz@elta.co.il> writes:

    Eli> Aren't attachments clearly marked in the message as being
    Eli> such?  Can't Emacs look for those markers (the part
    Eli> delimiters in a multi-part message) and refrain from decoding
    Eli> binary data while decoding text?

Yes and yes.  It's complex, though, and coding is not an area where
you want that.  For example, consider that the state of the buffer is
fragile, partly decoded to multibyte and partly raw unibyte.  Failure
to handle an error while decoding risks crashes.

    Eli> I see one significant disadvantage of this design: it will
    Eli> require thorough rewrite of many parts in RMAIL, since the
    Eli> code as it is now assumes a single buffer, narrowed as
    Eli> required.  I don't have enough information and experience to
    Eli> judge whether this is a serious disadvantage, though.

It's surely possible to maintain the single buffer model by adding a
mail-coding-system.  But I think that will make the code less modular,
require extensive duplication of existing functionality, be harder to
maintain, and present greater risk of undetected corruption (and even
crashes) than using the presentation buffer model.

I've presented my opinion, but that's all it is.  At the very least it
exposes some of the potential pitfalls, and thus could help with
dealing with them.

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