From: Eli Zaretskii <eliz@is.elta.co.il>
Cc: "Kai Großjohann" <Kai.Grossjohann@CS.Uni-Dortmund.DE>,
"Andreas Schwab" <schwab@suse.de>,
emacs-devel@gnu.org
Subject: Re: ChangeLog and unification
Date: Wed, 20 Feb 2002 08:25:45 +0200 (IST) [thread overview]
Message-ID: <Pine.SUN.3.91.1020220081524.21448C@is> (raw)
In-Reply-To: <200202181706.g1IH6ii10640@rum.cs.yale.edu>
On Mon, 18 Feb 2002, Stefan Monnier wrote:
> The unify-on-encode is safe and does not do unification.
What will it do if you yank a string with Latin-2 characters and then
save the buffer? Assuming that buffer-file-coding-system is
iso-2022-7bit, will it save those Latin-2 characters as Latin-2 or as
Latin-1? Also, what if I type characters with a latin-2 input method,
or with keyboard-coding-system set to latin-2--will the characters be
saved as Latin-2 or Latin-1?
> All it does is to allow saving latin-1 chars into a latin-2 file (as long
> as the latin-1 chars also exist in latin-2, of course).
In a file encoded with one of the iso8859-x encodings, this is indeed a
no-op. The plot might thicken when you use iso-2022-derived encodings,
which tag characters with their charset id. (I say ``might'' because I
really don't know what happens: I didn't yet have time to give
unify-on-* modes a serious test ride.)
> I really think unify-on-encode should be turned ON by default
> because I still haven't heard of any reasonable scenario where it can
> do anything undesirable.
You may be right, but the bitter experience with Mule-related issues
teaches me that we should be extra-cautious with turning features on by
default.
> Actually, I can't even think of any reason
> why we should try to make it possible to turn it off.
That is almost certainly a bad idea: it should be possible to turn off
_any_ feature, certainly a Mule-related one. Someone, some day, will
want that.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel
next prev parent reply other threads:[~2002-02-20 6:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-16 8:02 ChangeLog and unification Eli Zaretskii
2002-02-16 16:14 ` Kai Großjohann
2002-02-17 16:49 ` Richard Stallman
2002-02-16 16:53 ` Andreas Schwab
2002-02-16 18:05 ` Eli Zaretskii
2002-02-17 9:43 ` Kai Großjohann
2002-02-18 17:06 ` Stefan Monnier
2002-02-19 21:31 ` Richard Stallman
2002-02-20 6:27 ` Eli Zaretskii
2002-02-20 6:25 ` Eli Zaretskii [this message]
2002-02-20 15:04 ` Stefan Monnier
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=Pine.SUN.3.91.1020220081524.21448C@is \
--to=eliz@is.elta.co.il \
--cc=Kai.Grossjohann@CS.Uni-Dortmund.DE \
--cc=emacs-devel@gnu.org \
--cc=schwab@suse.de \
/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).