unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Per Starbäck" <per@starback.se>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: [SPG,spf=20]Re: Why ("/#[^/]+#\\'" . emacs-mule) ?
Date: Tue, 26 Mar 2013 16:57:58 +0100	[thread overview]
Message-ID: <CADkQgvtg97kAv=82K_eQh2wjcxEPKku8ALKCFGs443NhpmK=8w@mail.gmail.com> (raw)
In-Reply-To: <83sj3j1sa8.fsf@gnu.org>

>> 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.



      parent reply	other threads:[~2013-03-26 15:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-25 13:08 Why ("/#[^/]+#\\'" . emacs-mule) ? Per Starbäck
2013-03-25 13:21 ` Andreas Schwab
2013-03-25 13:59   ` Eli Zaretskii
2013-03-25 14:13 ` Eli Zaretskii
2013-03-25 14:50   ` Andreas Schwab
2013-03-26 15:57   ` Per Starbäck [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADkQgvtg97kAv=82K_eQh2wjcxEPKku8ALKCFGs443NhpmK=8w@mail.gmail.com' \
    --to=per@starback.se \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).