emacs-devel
[Top][All Lists]
Advanced

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

Re: request to revert the chnage of revno 112925


From: Stefan Monnier
Subject: Re: request to revert the chnage of revno 112925
Date: Wed, 19 Jun 2013 08:59:24 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

> 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



reply via email to

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