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

[Katsumi Yamaoka <yamaoka@jpl.org>]

>>>>> Aidan Kehoe wrote:
[...]

> GNU Emacs doesn't use the Unicode API for file names?

No, GNU Emacs does not have such a feature.  IIUC filename coding
is controlled by only `default-file-name-coding-system'; a non-nil
value of `file-name-coding-system' can override it but is normally
nil.

> Is there a good reason why not?

I don't know.  But handling of those two variables is easy to
understand at least for me.

[...]

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

I imagine it is similar to DOS machines in which shift_jis is
used for file names in Japan.  (Though I don't know how files
are on OS X, since my daughters don't give me leave to touch
their MacBooks.)

[...]

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

I saw what you meant at last.  The key is the `file-name' coding
system (I didn't know it!), which defaults to something according
to the locale name.
In XEmacs 21.5, binding of `file-name-coding-system' to nil changes
`file-name' even if `file-name-coding-system' is nil from the outset.

--8<---------------cut here---------------start------------->8---
emacs-version
 => "21.5  (beta28) \"fuki\" XEmacs Lucid"

(getenv "LC_CTYPE")
 => "ja_JP.UTF-8"

file-name-coding-system
 => nil

(get-coding-system 'file-name)
 => #<coding-system utf-8 unicode(utf-8)>

(let ((file-name-coding-system nil)))
 => nil

(get-coding-system 'file-name)
 => #<coding-system binary no-conversion eol-type=lf>
--8<---------------cut here---------------end--------------->8---

Moreover, binding of `file-name-coding-system' to any coding system
seems to be a trigger to make the `file-name' coding sysem binary.

--8<---------------cut here---------------start------------->8---
(get-coding-system 'file-name)
 => #<coding-system utf-8 unicode(utf-8)>

(let ((file-name-coding-system 'iso-2022-jp))
  (get-coding-system 'file-name))
 => #<coding-system iso-2022-jp iso2022(g0=ascii, g1=nil, ...

(get-coding-system 'file-name)
 => #<coding-system binary no-conversion eol-type=lf>
--8<---------------cut here---------------end--------------->8---

Anyway I still believe there is no reason to abolish the
`nnmail-pathname-coding-system' control in Gnus.  However, for
the momemnt I have no idea to cope with that behavior.  Isn't
there a chance to make it work like XEmacs 21.4?

--8<---------------cut here---------------start------------->8---
emacs-version
 => "21.4 (patch 22) \"Instant Classic\" XEmacs Lucid"

(getenv "LC_CTYPE")
 => "ja_JP.eucJP"

file-name-coding-system
 => iso-2022-jp

(get-coding-system 'file-name)
 => #<coding_system iso-2022-jp>

(let ((file-name-coding-system nil)))
 => nil

(get-coding-system 'file-name)
 => #<coding_system iso-2022-jp>

(let ((file-name-coding-system 'euc-jp))
  (get-coding-system 'file-name))
 => #<coding_system euc-jp>

(get-coding-system 'file-name)
 => #<coding_system iso-2022-jp>
--8<---------------cut here---------------end--------------->8---

Or any solution is welcome.  I tried this wrapper and failed:

--8<---------------cut here---------------start------------->8---
(defmacro nnmail-with-pathname-coding-system (&rest forms)
  "Bind `file-name-coding-system' while running FORMS.
A non-nil value of `nnmail-pathname-coding-system' will be used for
decoding and encoding file names."
  (if (featurep 'xemacs)
      `(let ((ocode (when (featurep 'file-coding)
		      (get-coding-system 'file-name)))
	     (file-name-coding-system nnmail-pathname-coding-system))
	 (unwind-protect
	     (progn ,@forms)
	   (when ocode
	     (copy-coding-system ocode 'file-name))))
    `(let ((file-name-coding-system nnmail-pathname-coding-system))
       ,@forms)))
--8<---------------cut here---------------end--------------->8---

>> [...] 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.

Confirmed.

Regards,