From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Per_Starb=E4ck?= Newsgroups: gmane.emacs.devel Subject: Re: [SPG,spf=20]Re: Why ("/#[^/]+#\\'" . emacs-mule) ? Date: Tue, 26 Mar 2013 16:57:58 +0100 Message-ID: References: <83sj3j1sa8.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1364313492 19885 80.91.229.3 (26 Mar 2013 15:58:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Mar 2013 15:58:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 26 16:58:39 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 1UKWGg-00005h-TF for ged-emacs-devel@m.gmane.org; Tue, 26 Mar 2013 16:58:35 +0100 Original-Received: from localhost ([::1]:55223 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKWGI-0006jV-M6 for ged-emacs-devel@m.gmane.org; Tue, 26 Mar 2013 11:58:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKWGE-0006g1-TI for emacs-devel@gnu.org; Tue, 26 Mar 2013 11:58:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKWGD-0007mU-FB for emacs-devel@gnu.org; Tue, 26 Mar 2013 11:58:06 -0400 Original-Received: from mail-la0-x235.google.com ([2a00:1450:4010:c03::235]:41764) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKWG8-0007kD-39; Tue, 26 Mar 2013 11:58:00 -0400 Original-Received: by mail-la0-f53.google.com with SMTP id fr10so13608292lab.26 for ; Tue, 26 Mar 2013 08:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aO3FRt21XwpSElkE8PF1LAEPVsg49s1vKz7l9BSd5Mo=; b=O7b7vSVdmDCQukHV/GYU1h7y6ijLJzDQhKquCQCVdhAjPNx0lc+mEtjQ9gwmw199TU 9i6aGRzsoRTFiPRTLWS0mrsN0+xzN3ruziF8GXLIUpym39+BEElq41jHwDlr1oBxJzs1 atUhggnSSiRKf6922mT09CJz3VBnmYB4O+9awtUa4B/7fm5KnXAwoNbvqql4jh9Hy1+C 78Gu1dmoItD05gBD1lo+6oclhPlBJwg/lkjP0LaiUokgL7I+k0oVDGGn7v2uBFwEQ/qO DAKAVqbWGV3ncB3QuMPg2k8PsLq6WIuW/uQ2XIKFpW5jmP/xrKN3aQYJYA7QvIf+JNyE WLYQ== X-Received: by 10.112.143.129 with SMTP id se1mr2436360lbb.120.1364313478224; Tue, 26 Mar 2013 08:57:58 -0700 (PDT) Original-Received: by 10.114.76.76 with HTTP; Tue, 26 Mar 2013 08:57:58 -0700 (PDT) In-Reply-To: <83sj3j1sa8.fsf@gnu.org> X-Google-Sender-Auth: 8iHQIvySVKnJKaeKS1LZY1Cbhc8 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::235 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:158222 Archived-At: >> Very often when I open them I have to immediately use >> revert-buffer-with-coding-system because they are utf8 files. > > Strange that you need that. When I do "M-x recover-this-file RET", I > get a buffer in utf-8-emacs-unix, which is what I expect. I wasn't talking about recover-this-file though. I was talking about just opening the file. > The purpose is back-compatibility with auto-save files from prior > versions. Back-compatibility is nice, but if we only can open old files *or* new files correctly the choice should obviously be the new files. But is that choice even necessary? I dug up an old autosave file I had (from 2003) with non-ascii characters in it. Opening it in an Emacs of today worked fine, identifying it correctly as emacs-mule-unix. But the setting in auto-coding-alist wasn't necessary for that, but that was done by normal coding-recognition as well. I removed the entry ("/#[^/]+#\\'" . emacs-mule) from auto-coding-alist, and now I can open both old and new autosave files correctly. If there are no non-ascii characters I get undecided instead of emacs-mule with the same buffer contents, which I don't see as a drawback. I think the current situation where Emacs can't correctly open files it is creating itself doesn't make sense. What would make sense is one of: 1. Remove the #-line in auto-coding-alist and let Emacs detect coding system normally. Maybe it won't work for some file, I don't know, but that is no big deal since you don't open these that often. 2. Replace emacs-mule with utf-8-emacs so it works for current files. It won't work for old autosave files, but that is no big deal since you almost never open those. 3. Make some special detection rule for autosave files that only detects if it is utf-8-emacs or emacs-mule. The "perfect" solution, but too ambitious for this.