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

["Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>]

> Would it be possible to have different coding-systems (the decoding of
> octets from a file into characters in a buffer) for different ranges
> of octets in a file?

Of course, it's possible: coding systems are operations, not data.
Emacs offers straightforward ways to apply those operations to whole
files when reading and saving them, as well as straightforward
ways to apply those operations to parts of a buffer.

> For example: in a file of 2000 octets, octet 1-1000 would be decoded
> using ISO-8859-1, octet 1001-1500 with UTF-8, 1501-2000 with
> (currently non-existent?)  Quoted-Printable and so on.  This would in
> my opinion allow a pretty way of handling MIME messages.

quoted-printable is not a coding-system.  As for the rest, I don't
see what's preventing you from doing it.  After all Gnus does is.
I.e. load the raw undecoded file, parse its content to figure out
where parts begin and end and what coding-system to use for them
(and maybe also un-base64 or un-qp them) and then apply
decode-coding-region.
Upon saving, just do the opposite.

> Though I can't come up with any other uses except for the proposed
> Rmail usage for different coding-systems for different regions, I
> don't see how it is nonsense.  It is like opening a file constructed
> by concatenating several files with different character encodings (and
> knowledge of what part of the file uses what encoding qould be
> extracted from the MIME data).  Do you see what I'm trying to
> accomplish?

I still don't understand what you want that's not already present.

> Unless I have overlooked something, I *do* think it would be possible
> to handle MIME messages nicely without replacing the encoded data, if
> the facilities for decoding different parts of a file (which is done
> with a coding-system, right?) with different character encodings
> exist.

I don't understand what you mean by "replacing".


	Stefan