emacs-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Unicode Lisp reader escapes


From: Stefan Monnier
Subject: Re: [PATCH] Unicode Lisp reader escapes
Date: Sun, 14 May 2006 23:27:20 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

>> Forcing it to nil for a particular file is maybe too much work to implement
>> compared to th benefit.
>> Maybe an easier solution is to add a file-local variable
>> `no-8859-unification' such that if that file is loaded in an Emacs which
>> is configured to use unify-8859-on-decoding it signals an error.
>> 
>> It could then be added to files like ucs-tables.el.

> [Nitpick: ucs-tables.el is encoded in ISO 2022.  Most of Emacs' files
> containing m18n characters are, AFAIK.  I don't know the reason.  Maybe
> because it's 7bit, but still ASCII compatible. ]

I'm not sure I understand the nitpick:
- the reason most files use iso-2022 is because it was the only mildly
  standard generic encoding well supported by Emacs (utf-8 is slowly
  getting there, but Emacs-CVS's support for it is still behind).

- ucs-tables.el, if saved as utf-8, would not do the same any more: it
  relies on the various "equivalent" 8859 chars to be distinguished (as is
  done in iso-2022, and as can't be done in utf-8).  That's also why opening
  it with unify-8859-on-decoding is wrong: you're not looking at the right
  code any more because you basically get what you'd get if it had been
  saved in a unified encoding such as utf-8.

> How about just issuing a warning with the warning message containing a
> description of the effects and of what to do to change the settings?

>   (warn "You have enabled ... but this source file contains
> characters from ... Emacs has ... This might or might not be what
> you want ... To restore the defaults do ... bla bla ...
> ... you might want to use `emacs-mule' as coding system for Emacs Lisp
> source files ..."))

I'm actually not sure if using emacs-mule instead of iso-2022 helps.
It depends on whether or not unify-8859-on-decoding is also applied to
emacs-mule "decoding".

> Though, the only way to deal with the latter would be to modify the
> Lisp printer for writing *.elc files so that it escapes non-ascii
> characters whereever possible with the new \u syntax. This would be
> another solution to the problem we are discussing.]

This would break the compilation of ucs-tables.el.


        Stefan




reply via email to

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