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

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

> When Emacs loads a file (that is supposed to be encoded in for example
> ISO 2022, a 7 bit based encoding), does it first load the file
> contents into a buffer as ASCII text and then applies
> decode-coding-region to the entire buffer (conceptually)?

It's optimized, but conceptually, yes, that's what it does.

> Using decode-coding-region modifies the buffer contents because the
> actual characters present in the buffer change (the two characters AA
> might become the character Å or whatever, and hence the buffer
> contents has been modified).

(let ((mod (buffer-modified-p)))
  (decode-coding-region start end)
  (restore-buffer-modified-p mod))

Why does it matter if the buffer is "modified" or not ?
I still don't get it.  Note, I'm not trying to turn you away,
but I really don't understand.

> 1. I like the simple model of Rmail seeing a message as a narrowed
>    down part of the actual mail folder file (that is, no separate
>    display buffer).

What do you like about it, other than the concept ?

> 2. It would be desirable that Rmail didn't modify the underlying
>    message (= save decoded message), at least save it to disk.

I have trouble parsing this sentence.

Could you describe very concretely what you want to do ?
Do you want to stores emails in fully decoded form in the Rmail file ?
If so, why wouldn't "fully decoded" use the emacs-mule coding-system ?

> Number 2 leads, due to the strong association between the message and
> the mail folder file, that it also is undesirable to modify the
> buffer, which is what decode-coding-region does.  Instead, why not
> decode the parts of the file that are encoded in a different manner
> "correctly" the first time?

Why does it matter whether it's the first time or the second ?
In either case, it's different and needs to be re-encoded when saving.

> Gnus doesn't have Rmails strong association of the message actually
> being a narrowed down region of the mail folder file.  It is fine for
> Gnus to create a separate buffer wholly intended for working with the
> message.  That is why Gnus can load the encoded data into the buffer,
> do decode-coding-region, insert buttons and play around with the
> buffer contents--the buffer will be thrown away later.

Yup, it's a very clean way to do things, indeed.  You can decode all
you want, throw stuff away, rewrite it, etc to your heart's content
while still being 100% sure that you didn't mess up anything.
Also it can be significantly more efficient since working on a 10KB
display buffer is more efficient than working on a 100MB Rmail
folder file.  Sounds like a winner to me ;-)
Which part do you not like ?
Admittedly, when you don't have much to do to make the message "viewable",
copying the message to a separate buffer is a waste and is less efficient
than just narrow-and-go.  Is that what bothers you ?

> >> 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.
> 
> I don't want to first load encoded data into the buffer, then decode
> it (thereby modifying the contents).  I want the decoding to happen
> before the characters hit the Emacs buffer.  And I want to use
> different decoding for different parts of the underlying raw bytes.

That describes *how* you want to reach your goal, but it doesn't
describe your goal.


	Stefan