RE: Loading souce Elisp faster

["Drew Adams" <drew.adams@oracle.com>]

>     Do we need to support non-utf-8 elisp files? I say we 
>     convert all of them (those in our control) to utf-8 and
>     be done with it.
> 
> We could do this, but we still need to support other people's 
> Lisp code, so we can't drop support for other coding systems.
> 
> Even changing the default might break things for users.

Amen.

Some files need to be compatible with older Emacs versions.
Embedded Unicode chars in such files can be problematic.

(And using a BOM is also not a good idea, IMHO.)

What is wrong with continuing to use an explicit declaration for UTF-8?  I saw
no good argument for such a change.

This is the closest to an argument that I've seen:

> And given that utf-8 should be the standard encoding for Elisp
> files (if not quite now, surely in some not too distant future),
> this is an important case.

Where "this" is the case of optimizing the use of UTF-8 files by avoiding an
unnecessary `load-with-code-conversion'.

But AFAICT, nothing stops Emacs from doing that anyway.  Just declare that the
file is UTF-8 explicitly.  Where's the beef?

I am all in favor of using Unicode in Emacs and beyond.  Best thing that's
happened to Emacs in years, in fact.  But just because an encoding becomes the
new "standard" does not mean that other encodings should no longer be supported.

And that means continued support in older releases as well.  It does no good to
introduce something now to distinguish non-UTF-8 in new releases, if that won't
be recognized in older releases.