Re: Emacs Lisp's future

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,
>     emacs-devel@gnu.org
> Date: Wed, 15 Oct 2014 16:17:52 +0900
> 
>  > Conversely, it appears that you did not read the file
>  > admin/notes/unicode carefully;
> 
> "It appears that you have not studied Unicode carefully", as there is
> nothing in that file that suggests anything but work is involved in a
> conversion that loses no character information, since the external
> coding system utf-8-emacs is available.  Even that can be dispensed
> with, and pure Unicode used, with a little more work (use the PUA,
> that's what it is there for!)

utf-8-emacs is a private encoding used and understood by Emacs alone,
so encoding Emacs files in that would make them unusable
(unsearchable, unreadable, etc.) with anything but Emacs.

As for using PUA, you have been told just a few days ago why this is
not going to work with Emacs.

> The metadata (language, for which original coded character set is a
> proxy) can be provided either with a markup language (eg, XML or even
> HTML) or using Plane 14 tags (but I wrote that already).

It is easy to suggest such major endeavors to other projects in which
you have no intention to become involved.  From the Emacs side, this
would be a terrible waste of resources, since the "problem" is already
solved in Emacs by other means, which work well, based on several
years of real-life experience.

>  > if you had, you would not be asserting so blithely that there is
>  > "no barrier" to converting all Emacs source files to UTF-8.
> 
> I stand corrected.  No *technical* barrier.  It does require
> nontrivial work: simply filtering through iconv is not enough.
> 
> There's also a political barrier: I believe that characters are
> characters, and may be shared across traditional character set
> boundaries, and that the presentation layer should specify
> presentation.  Dr. Handa prefers that presentation be encoded in the
> content.  I have no stomach for that argument.

The statement that UTF-8 is a de-facto Emacs "locale" still stands.
And so having Emacs behave in a way that makes it easy to work with
these files, including those few that for various reasons are encoded
differently, is still a valuable feature.  Your argument that Emacs
files have no single encoding and therefore there's no reasonable way
to support them is struck down.