Re: nnmail-pathname-coding-system breaks my XEmacs.

[Aidan Kehoe <kehoea@parhasard.net>]

 Ar an triú lá déag de mí Eanair, scríobh Katsumi Yamaoka: 

 > In a sense, it is the reason Emacs provides the variable
 > `default-file-name-coding-system' and lets
 > `file-name-coding-system' be normally nil (like
 > `coding-system-for-read' and `coding-system-for-write' are).

But file system pathname encodings don’t vary remotely as much on a single
system as can file content encodings. And dynamic let bindings can be used
for the rare instances that they do vary.

 > It is helpful that the coding system used for encoding and
 > decoding filenames is initialized to the one suitable to the
 > language a user uses.  In the Japanese language environment
 > `default-file-name-coding-system' will be `euc-jp' (or possibly
 > `utf-8') in UNIX or similar systems, and `shift_jis' in DOS
 > machines.  Those are helpful enough for daily work in Japan.

GNU Emacs doesn’t use the Unicode API for file names? Is there a good reason
why not?

 > However, some newsgroups use Latin characters, Chinese characters,
 > etc., for which neither `euc-jp' nor `shift_jis' is suitable.
 > 
 > (Especially for testing Gnus, I subscribe to many non-ASCII
 >  groups even if I'm not capable to read all of those languages.)
 > 
 > OTOH, `utf-8' seems to be the best choice for such a purpose,
 > but setting `default-file-name-coding-system' (or
 > `file-name-coding-system') to `utf-8' is not always a good idea
 > since clients other than Emacs cannot necessarily deal with
 > filenames encoded by `utf-8', 

UTF-8 is *enforced* on OS X, in contrast to most Unix environments. 

 > and Emacs 21, XEmacs 21.4 and SXEmacs don't support `utf-8' fully (even
 > if the Mule-UCS package is loaded).
 > 
 > Therefore I concluded Gnus needs the coding system, that is not
 > necessarily the same as the one used for arbitrary file names,
 > for files for non-ASCII newsgroup names.  My fault is that I did
 > not take care of the *default* coding system used for file names
 > in XEmacs.
 > 
 > > This is initialised correctly these days (except if you're dealing,
 > > say, with an external or network drive where your host OS doesn't
 > > understand its file name encoding; but nothing can really initialise
 > > correctly in that case) though I admit there were years where we
 > > dealt with it very badly.
 > 
 > So, how about changing the `let' bindings here and there in this
 > way?
 > 
 > (let ((file-name-coding-system
 >        (if (featurep 'xemacs)
 > 	   (or nnmail-pathname-coding-system
 > 	       ;; XEmacs w/o `file-coding' doesn't provide it.
 > 	       (and (featurep 'file-coding)
 > 		    file-name-coding-system))
 > 	 nnmail-pathname-coding-system)))

That will work, yes. Because of the stupid hackery I mentioned in my earlier
mail it will break file-name-coding-system if a user actually uses use
nnmail-pathname-coding-system binding, but that’s a slightly better
situation than the current one, where file-name-coding-system is broken
afterwards whether the user uses nnmail-pathname-coding-system or not. 

 > [...] In my Fedora 10 Linux box, both XEmacs 21.5 that was downloaded
 > from hg today and XEmacs 21.4 from CVS set `file-name-coding-system' to
 > nil for the "ja_JP.UTF-8" locale, though.

Yes, that’s a cosmetic bug on our part. The file-name coding system alias,
which is actually what’s used in the C code, is supposed to be equivalent to
the file-name-coding-system variable, but I hadn’t maintained this
relationship in writing the startup code. I’ll fix that. 

Try

LC_CTYPE=ja_JP.UTF-8 xemacs-21.5-b28 -batch -eval "(princ (coding-system-aliasee 'file-name))"

if you want to check that. 

 > > (Note that nil, your default, corresponds to the binary,
 > > no-conversion coding system under XEmacs, which, for example, Mac OS
 > > X will not accept when asked to create a file name with non-ASCII
 > > characters in that encoding, it requires valid UTF-8.)
 > 
 > Once I have modified mm-(decode|encode)-coding-(string|region)
 > so as to do nothing in XEmacs with the coding system nil.  But I
 > overlooked what happens when `file-name-coding-system' is nil.
 > I think XEmacs' way, i.e. treating nil as binary, is not a good
 > idea.

I agree. I don’t know why that decision was made.

-- 
¿Dónde estará ahora mi sobrino Yoghurtu Nghe, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?