bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#35383: 27.0.50; Complete process of decoding Gnus group names


From: Eli Zaretskii
Subject: bug#35383: 27.0.50; Complete process of decoding Gnus group names
Date: Fri, 26 Apr 2019 13:55:19 +0300

> Date: Fri, 26 Apr 2019 17:08:24 +0900
> From: Katsumi Yamaoka <address@hidden>
> Cc: address@hidden, address@hidden
> 
> > It is not unnecessary, because that file could be visited normally in
> > Emacs.  So even if you have to bind coding-system-for-read for some
> > reason (and I admit I don't understand the reasons very well, and in
> > particular this will not affect 'read' or any other primitive that
> > is supposed to be reading from an already decoded buffer/string),
> > there are still valid reasons to have the cookie in the file.
> 
> Well, I don't know why the active files need a coding cookie, but
> what adds it is `gnus-write-active-file' that only gnus-agent and
> gnus-cache use; `nnmail-save-active' that many mail back ends use
> does not add a coding cookie.  Even so, I have no trouble with my
> nnml active file that contains non-ASCII group names.  The file
> is utf-8 encoded and it is Emacs' default (IIUC), so I cannot
> think any reason why the cookie is required.

You are probably in a UTF-8 locale, so your defaults facilitate
detecting the right encoding.  In non-UTF-8 locales this might not be
that easy, Emacs could guess wrong.

More importantly, utf-8-emacs and utf-8 are not the same, the
differences are subtle, but they do exist.  We use utf-8-emacs for
anything that should support any character representable inside Emacs
buffers and strings, so using it here seems correct.  But if someone
wants to visit this file with "C-x C-f", e.g., to manually fix
something there, they should be able to do that without risking
incorrect decoding.

So I think the cookie should stay, especially as it can never do any
harm in this context, AFAIU.





reply via email to

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