Re: request to revert the chnage of revno 112925

[Stefan Monnier <monnier@iro.umontreal.ca>]

> So, the above change does not improve the performance that much.

The change was not done for performance reasons.

> In addition, as iso-2022-jp and iso-2022-7bit have been the
> most correctly detected coding systems in any environments,
> there are many packages that uses them for *.el files (at
> least in Japan).  Now many of them doesn't work.

Then maybe we should use a new coding-system which does falls back on
iso-2022 if some incorrect utf-8 byte sequence is found?

> In some sence, the above change is a regression because it
> disables Emacs' facility to automatically decode ISO 2022
> based 7-bit encodings, and we should notify users about such
> a change in advance, for instance, by showing warnings by
> byte-compiler for non-UTF-8 and no-coding-tag *.el files for
> a while (perhaps while Emacs' version is 24.*).

I knew that the change was "risky".  Admittedly, part of the motivation
was to see how much breakage we'd bump into.

But the core of what I want: make it so that utf-8 Elisp files are
always recognized correctly, even in the absence of a coding: tag, and
regardless of the user's locale.
The way I implemented it broke recognition of iso-2022, but if there;s
some other way that doesn't break it, that's even better.


        Stefan