unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.

  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).