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: Sun, 27 Sep 2015 13:36:08 +0300

> Date: Sun, 27 Sep 2015 13:16:18 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden,
>       address@hidden
> 
> > From: David Kastrup <address@hidden>
> > Cc: Paul Eggert <address@hidden>,  Eli Zaretskii <address@hidden>,  
> > address@hidden,  address@hidden
> > Date: Sun, 27 Sep 2015 12:04:45 +0200
> > 
> > Andreas Schwab <address@hidden> writes:
> > 
> > > Paul Eggert <address@hidden> writes:
> > >
> > >> Yes, and those files are a pain to look at with Emacs now, since it
> > >> typically misguesses their encodings.  Presumably Emacs should be looking
> > >> at .po files' charset= decorations.
> > >
> > > It does already if you use the po-mode distributed with gettext.
> > 
> > gettext being the standard GNU i18n mechanism, wouldn't it make sense to
> > keep the latest version distributed with Emacs rather than requiring
> > users to manually install them?
> 
> We discussed that at some point in the past.  I don't remember why we
> decided not to do that, but a search in the archives might tell.
> Maybe those reasons are no longer relevant.

I've misremembered.  The discussion is here:

  http://lists.gnu.org/archive/html/emacs-devel/2002-03/msg00167.html

and, more importantly, its result is already in Emacs:

file-coding-system-alist is a variable defined in ‘C source code’.
Its value is shown below.

[...]
Value: (("\\.dz\\'" no-conversion . no-conversion)
 ("\\.txz\\'" no-conversion . no-conversion)
 ("\\.xz\\'" no-conversion . no-conversion)
 ("\\.lzma\\'" no-conversion . no-conversion)
 ("\\.lz\\'" no-conversion . no-conversion)
 ("\\.g?z\\'" no-conversion . no-conversion)
 ("\\.\\(?:tgz\\|svgz\\|sifz\\)\\'" no-conversion . no-conversion)
 ("\\.tbz2?\\'" no-conversion . no-conversion)
 ("\\.bz2\\'" no-conversion . no-conversion)
 ("\\.Z\\'" no-conversion . no-conversion)
 ("\\.elc\\'" . utf-8-emacs)
 ("\\.el\\'" . prefer-utf-8)
 ("\\.utf\\(-8\\)?\\'" . utf-8)
 ("\\.xml\\'" . xml-find-file-coding-system)
 ("\\(\\`\\|/\\)loaddefs.el\\'" raw-text . raw-text-unix)
 ("\\.tar\\'" no-conversion . no-conversion)
 ("\\.po[tx]?\\'\\|\\.po\\." . po-find-file-coding-system)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 ("\\.\\(tex\\|ltx\\|dtx\\|drv\\)\\'" . latexenc-find-file-coding-system)
 ("" undecided))

And the bundled po.el already defines po-find-file-coding-system.

So it sounds like we simply have a bug here.

But once again, the handling of *.po files is not the issue here.  The
issue is whether we can ignore the possibility of non-UTF-8 encodings
in locales whose codeset is not UTF-8.




reply via email to

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