[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Prevent iso-8859 unification for some files?

From: Andreas Schwab
Subject: Re: Prevent iso-8859 unification for some files?
Date: Mon, 04 Feb 2002 11:40:56 +0100
User-agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.2.50 (ia64-suse-linux)

Kenichi Handa <address@hidden> writes:

|> Andreas Schwab <address@hidden> writes:
|> > Kenichi Handa <address@hidden> writes:
|> > |> Andreas Schwab <address@hidden> writes:
|> > |> > IMHO the right way to fix the ucs-table breakage is to use hex escapes
|> > |> > instead of literal characters, since the file depends on exact codes. 
|> > |> > you agree I'll do the necessary changes.
|> > |> 
|> > |> There's an easier solution.  We can make a new coding system
|> > |> that is same as iso-2022-7bit except for that it explicitly
|> > |> has a empty translation table.
|> > I don't think this is necessary, since using emacs-mule is already enough
|> > to prevent unification.  But I still think that using hex escapes is
|> > better for future compatibility.
|> Why?  Using hex escapes means that we embed internal
|> character codes.  They will be changed in the future
|> (i.e. in unicode-base Emacs).  But, emacs-mule and
|> iso-2022-7bit-no-trans are decoded correctly even in the
|> future.
|> And, it seems that it's a bug rather than a feature that
|> emacs-mule ignore translation table (I didn't notice it
|> until now :-().

That's what I meant with future compatibility.

|> By the way, as unicode-base Emacs won't need ucs-table.el,
|> we don't have to care for future compatibility.

Well, in this can we don't have to worry about this and can just use hex


Andreas Schwab, SuSE Labs, address@hidden
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 N├╝rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]