Re: Prevent iso-8859 unification for some files?

[Andreas Schwab]

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. 
 If
|> > |> > 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
escapes.

Andreas.

-- 
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."