Re: request to revert the chnage of revno 112925

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

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