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

[Katsumi Yamaoka <yamaoka@jpl.org>]

>>>>> Aidan Kehoe <kehoea@parhasard.net> wrote:
>> cf. (info "(gnus)Non-ASCII Group Names")

> If this reflects the current state of affairs:

> nnmail-pathname-coding-system

>     The value of this variable should be a coding system or nil (which is
>     the default). The nnml back end, the nnrss back end, the NNTP marks
>     feature (see section 6.2.1.4 NNTP marks), the agent, and the cache use
>     non-ASCII group names in those files and directories. This variable
>     overrides the value of file-name-coding-system which specifies the
>     coding system used when encoding and decoding those file names and
>     directory names.

>     In XEmacs (with the mule feature), file-name-coding-system is the only
>     means to specify the coding system used to encode and decode file
>     names. Therefore, you, XEmacs users, have to set it to the coding system
>     that is suitable to encode and decode non-ASCII group names. On the
>     other hand, Emacs uses the value of default-file-name-coding-system if
>     file-name-coding-system is nil. Normally the value of
>     default-file-name-coding-system is initialized according to the locale,
>     so you will need to do nothing if the value is suitable to encode and
>     decode non-ASCII group names.

>         (from http://www.gnus.org/manual/gnus_40.html )

> why aren't you just using file-name-coding-system?

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

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.
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', 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)))

Otherwise, does this simple way help?

(defvar nnmail-pathname-coding-system
  (if (and (featurep 'xemacs)
	   ;; XEmacs w/o `file-coding' doesn't provide it.
	   (featurep 'file-coding))
      file-name-coding-system)
  "*Coding system for file name.")

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.

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

Regards,