emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] master db828f6: Don't rely on defaults in decoding UTF


From: Eli Zaretskii
Subject: Re: [Emacs-diffs] master db828f6: Don't rely on defaults in decoding UTF-8 encoded Lisp files
Date: Fri, 25 Sep 2015 16:37:34 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Fri, 25 Sep 2015 08:21:59 -0400
> 
> > E.g., try saving a foo.el with the following contents:
> >
> >   (setq string "א“”")
> >
> > using cp1255, then kill the buffer and visit it again.
> 
> AFAIK saving in this way requires very explicit action on the part of
> the user.  She gets what she asked for.

Who does?  We are talking about 2 different people here, the one who
was sloppy forgetting the coding cookie, and another who visited it.

> I can imagine a future where we don't even support Elisp files using
> another coding system (i.e. throw away the load-with-code-conversion
> machinery).

I'm not sure this can be done.  AFAIK, a few files under leim/quail
are encoded with non-UTF encoding, and for a good reason.

> > More generally, I think we should require any text file in the Emacs
> > repository that includes non-ASCII characters to have an explicit
> > coding cookie, so that these subtle problems don't lie low because
> > most Emacs contributors live in UTF-8 locales.
> 
> My view OTOH is that the future is utf-8 only

If you know the future, perhaps you could suggest which shares of what
companies I should invest in?  Why waste such an important insight on
some insignificant piece of software?

> we need to find ways to go from here (i.e. "need a coding: tag for
> any non-ASCII file") to there.  I don't have an answer in general,
> but prefer-utf-8 is a step in that direction, which can be used for
> some class of files (e.g. Elisp).

I think there's no way from here to there, not as long as our encoding
detection's reliability is what it is.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]