From: Richard Stallman <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Different (buffer-file-)coding-systems for different regions of one buffer? (for Rmail MIME)
Date: Sat, 24 May 2003 19:19:40 -0400 [thread overview]
Message-ID: <E19JiIe-0007dN-5S@fencepost.gnu.org> (raw)
In-Reply-To: <87wughogc8.fsf@tleepslib.sk.tsukuba.ac.jp> (stephen@xemacs.org)
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.
It is important to have a way to edit the text that is displayed. It
is desirable but not very important to preserve the first charset
designation. If we can't do both, we should do the former.
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).
This is easy to do--just don't replace the original text unless the
user has edited the message.
The user must type an explicit command, currently e, to edit the
message. The edited text would be stored back into the file
only when the user exits edit mode (and not if he aborts the edit).
In addition, it is easy to compare the buffer contents with what is
produced by preparing the original message for display. If they are
the same, then don't alter the original message text.
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.
Right now, if I switch to buffer RMAIL, I see the message that is
selected in the buffer RMAIL. If that message is actually displayed
in another buffer, then switching to RMAIL won't show it, or won't
show it properly.
Perhaps we need a feature of "alias buffers". If we set up buffer
RMAIL to specify buffer *View RMAIL* as its alias, then when buffer
RMAIL is selected in a window, buffer *View RMAIL* will actually
appear in the window and will actually be the current buffer most of
the time. (You could still make RMAIL the current buffer by
explicitly calling set-buffer.)
Tar mode could also make use of this. And Info.
next prev parent reply other threads:[~2003-05-24 23:19 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
[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 [this message]
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=E19JiIe-0007dN-5S@fencepost.gnu.org \
--to=rms@gnu.org \
--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.