From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: request to revert the chnage of revno 112925 Date: Wed, 19 Jun 2013 20:54:13 +0900 Message-ID: <87k3lql3iy.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1371643108 20172 80.91.229.3 (19 Jun 2013 11:58:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Jun 2013 11:58:28 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 19 13:58:28 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UpH1v-0000Dq-9o for ged-emacs-devel@m.gmane.org; Wed, 19 Jun 2013 13:58:27 +0200 Original-Received: from localhost ([::1]:39539 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpH1u-0005GY-Jz for ged-emacs-devel@m.gmane.org; Wed, 19 Jun 2013 07:58:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35560) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpH1r-0005F3-8k for emacs-devel@gnu.org; Wed, 19 Jun 2013 07:58:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UpH1p-0006ea-Rq for emacs-devel@gnu.org; Wed, 19 Jun 2013 07:58:23 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45116) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpH1p-0006eW-Oj for emacs-devel@gnu.org; Wed, 19 Jun 2013 07:58:21 -0400 Original-Received: from [103.5.142.5] (port=52373 helo=shatin) by fencepost.gnu.org with esmtpa (Exim 4.71) (envelope-from ) id 1UpH1L-0001MR-1o for emacs-devel@gnu.org; Wed, 19 Jun 2013 07:58:21 -0400 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:160653 Archived-At: I'd like to revert the following change (revno 112925): 2013-06-11 Stefan Monnier * international/mule-conf.el (file-coding-system-alist): Use utf-8 as default for Elisp files. By my recent changes for tuning up ASCII and UTF-8 file reading, the speed for reading a UTF-8 file is almost the same in the following cases: * the file has coding: utf-8; tag * find-operation-coding-system returns utf-8 for the file (the current case of *.el files) * the file has no coding tag and utf-8 is the most preferred coding system * the file has no coding tag and utf-8 is the most preferred coding system among 8-bit encoding (which means that such 7-bit coding systems as iso-2022-jp may be more preferred) So, the above change does not improve the performance that much. 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. 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.*). --- Kenichi Handa handa@gnu.org