From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: request to revert the chnage of revno 112925 Date: Wed, 19 Jun 2013 16:49:38 -0400 Message-ID: References: <51C1D83E.7020501@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1371675082 26163 80.91.229.3 (19 Jun 2013 20:51:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Jun 2013 20:51:22 +0000 (UTC) Cc: Kenichi Handa , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 19 22:51:22 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 1UpPLd-0007x0-UT for ged-emacs-devel@m.gmane.org; Wed, 19 Jun 2013 22:51:22 +0200 Original-Received: from localhost ([::1]:38833 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpPLd-0004Ic-JQ for ged-emacs-devel@m.gmane.org; Wed, 19 Jun 2013 16:51:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpPKB-0002pJ-Np for emacs-devel@gnu.org; Wed, 19 Jun 2013 16:49:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UpPKA-0007oS-LQ for emacs-devel@gnu.org; Wed, 19 Jun 2013 16:49:51 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:34691) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpPK8-0007mx-L2; Wed, 19 Jun 2013 16:49:48 -0400 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.DIT.UMontreal.CA (8.14.1/8.14.1) with ESMTP id r5JKncQ6016244; Wed, 19 Jun 2013 16:49:38 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 97B6AB4178; Wed, 19 Jun 2013 16:49:38 -0400 (EDT) In-Reply-To: <51C1D83E.7020501@cs.ucla.edu> (Paul Eggert's message of "Wed, 19 Jun 2013 09:11:42 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4614=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4614> : streams <985155> : uri <1452789> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:160704 Archived-At: >> I'd like to find a better solution, but at first please >> clarify the requirements. > I assume these requirements should be the same for Elisp > files as for other files that Emacs is asked to read; No. We're talking here about files which can/will be shared by thousands of people who have very little in common in terms the kind of locale/coding-system they use. So it's important for the coding-system to be decided independently from the locale. This is not specific to Elisp, of course, it's true of most programming languages, and indeed most of those used to specify that the code had to be written in "pure ascii" for the code part and "anything compatible with ascii" for the comments. But nowadays, most programming languages are shifting towards allowing non-ascii in the code part and this is usually done by specifying an encoding such as utf-8. IOW I consider it a bug to have an Elisp files that use non-utf-8 encoding without an explicit coding: cookie. > If I edit a file that's undecided-xxx, and insert > a character that can be encoded either as UTF-8 or > as ISO-2022-JP say, the buffer becomes utf-8-xxx, > right? That depends on the locale. Which is why I prefer the use of utf-8 for ascii-only files. >> * What to do with an invalid UTF-8 file. Previously, >> find-file detects a proper coding-system for such a file. >> Now utf-8 is forced and any invalid UTF-8 byte sequences >> are decoded as raw bytes. > Surely this should be fixed: the file should be decoded > properly, as before. Yes, tho only as a temporary measure to give people time to fix their files. > I suggest going back to the old behavior (that's the normal > behavior for random files that Emacs edits, right?). These are not random files. > Elisp files normally don't contain null bytes; Most don't, indeed. But there's no reason why they shouldn't contain a nul byte, e.g. embedded in a string. > such files are not considered to be text files in the POSIXish world. The POSIX world doesn't care too much about labeling files as text-vs-binary except when it's really useful (e.g. to try and avoid spewing crap in the output of grep). Disallowing nul bytes in Elisp files doesn't serve any such purpose, AFAICT, so I think the natural POSIX behavior here would be to allow nul bytes. Stefan