From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
Cc: emacs-devel@gnu.org
Subject: Re: Different (buffer-file-)coding-systems for different regions of one buffer? (for Rmail MIME)
Date: Wed, 21 May 2003 18:29:15 -0400 [thread overview]
Message-ID: <200305212229.h4LMTFKo001277@rum.cs.yale.edu> (raw)
In-Reply-To: i56smr8j8lk.fsf@mao.acc.umu.se
> 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
next prev parent reply other threads:[~2003-05-21 22:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <i56wugl13qq.fsf@mao.acc.umu.se>
2003-05-21 2:43 ` Different (buffer-file-)coding-systems for different regions of one buffer? (for Rmail MIME) Kenichi Handa
2003-05-22 8:33 ` Richard Stallman
[not found] ` <i563cj8kz7e.fsf@mao.acc.umu.se>
2003-05-21 19:53 ` Stefan Monnier
[not found] ` <i56smr8j8lk.fsf@mao.acc.umu.se>
2003-05-21 22:29 ` Stefan Monnier [this message]
[not found] ` <i56u1bnn567.fsf@mao.acc.umu.se>
2003-05-22 3:41 ` Stephen J. Turnbull
[not found] ` <i56ptmateuj.fsf@mao.acc.umu.se>
2003-05-23 10:56 ` Stephen J. Turnbull
2003-05-23 12:03 ` Richard Stallman
2003-05-23 15:03 ` Stephen J. Turnbull
2003-05-24 23:19 ` Richard Stallman
2003-05-25 18:28 ` Kai Großjohann
2003-05-27 12:44 ` Richard Stallman
2003-05-26 5:20 ` Stephen J. Turnbull
2003-05-26 17:30 ` Eli Zaretskii
2003-05-27 10:03 ` Stephen J. Turnbull
2003-05-27 12:44 ` Richard Stallman
2003-05-27 15:12 ` Stephen J. Turnbull
2003-05-28 23:57 ` Richard Stallman
2003-05-29 8:20 ` Stephen J. Turnbull
2003-05-22 1:32 ` Kenichi Handa
2003-05-22 13:16 ` Kai Großjohann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200305212229.h4LMTFKo001277@rum.cs.yale.edu \
--to=monnier+gnu/emacs@rum.cs.yale.edu \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.