From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Loading souce Elisp faster Date: Mon, 25 Feb 2013 07:35:28 -0800 Message-ID: <75C9FC0FD46245178BDC311A05B53B3F@us.oracle.com> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1361806556 8566 80.91.229.3 (25 Feb 2013 15:35:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Feb 2013 15:35:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: , "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 25 16:36:17 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 1UA06C-0007yU-K6 for ged-emacs-devel@m.gmane.org; Mon, 25 Feb 2013 16:36:16 +0100 Original-Received: from localhost ([::1]:35740 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA05r-00015z-Ub for ged-emacs-devel@m.gmane.org; Mon, 25 Feb 2013 10:35:55 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:49129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA05k-00010j-Jc for emacs-devel@gnu.org; Mon, 25 Feb 2013 10:35:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UA05f-0004FP-H0 for emacs-devel@gnu.org; Mon, 25 Feb 2013 10:35:48 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:42045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA05f-0004F5-AT; Mon, 25 Feb 2013 10:35:43 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1PFZeVd006438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Feb 2013 15:35:41 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1PFZdRr012812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Feb 2013 15:35:40 GMT Original-Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1PFZduc016352; Mon, 25 Feb 2013 09:35:39 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Feb 2013 07:35:39 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac4TTWSCYxQxYFK7StC+pTaRCEmXfwAG+39g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:157319 Archived-At: > 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.