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

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

[Reiner Steib]

On Sun, Jan 11 2009, Aidan Kehoe wrote:

> Sehr geehrte Damen und Herren!

Since all of the recent matches for nnmail-pathname-coding-system in
ChangeLog point to Katsumi Yamaoka, a Japanese greeting would be more
appropriate.  ;-)

> Why is Gnus overriding file-name-coding-system? For example, in
> nnmh-active-number, and pretty much everywhere that
> nnmail-pathname-coding-system is used. In XEmacs 21.5 we have stupid hackery
> that maintains the file-name coding system alias as equivalent to the
> file-name-coding-system variable, but this doesn’t know about dynamic scope,
> so after I’ve used Gnus my file-name-coding-system is reset to binary, which
> is useless on OS X. If you’re using anything non-ASCII I imagine it’ll break
> under Gnus too, and if you’re not using anything non-ASCII, why bother
> messing with the variable at all? 
[...]
> Gnus v5.10.8
> XEmacs 21.5  (beta28) "fuki" 302136a857ec+ [Lucid] (i386-apple-darwin8.11.1, Mule) of Sat Jan 10 2009 on bonbon

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

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

[Katsumi Yamaoka]

>>>>> In <87hc45o6ea.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> On Sun, Jan 11 2009, Aidan Kehoe wrote:

> > Sehr geehrte Damen und Herren!

> Since all of the recent matches for nnmail-pathname-coding-system in
> ChangeLog point to Katsumi Yamaoka, a Japanese greeting would be more
> appropriate.  ;-)

I'll look into it tomorrow.  Sorry I have no time today.  Anyway
those `file-name-coding-system' uses are for files used of
non-ASCII group names.  cf. (info "(gnus)Non-ASCII Group Names")

> > Why is Gnus overriding file-name-coding-system? For example, in
> > nnmh-active-number, and pretty much everywhere that
> > nnmail-pathname-coding-system is used. In XEmacs 21.5 we have stupid hackery
> > that maintains the file-name coding system alias as equivalent to the
> > file-name-coding-system variable, but this doesn’t know about dynamic scope,
> > so after I’ve used Gnus my file-name-coding-system is reset to binary, which
> > is useless on OS X. If you’re using anything non-ASCII I imagine it’ll break
> > under Gnus too, and if you’re not using anything non-ASCII, why bother
> > messing with the variable at all?
> [...]
> > Gnus v5.10.8
> > XEmacs 21.5  (beta28) "fuki" 302136a857ec+ [Lucid] (i386-apple-darwin8.11.1, Mule) of Sat Jan 10 2009 on bonbon

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

[Aidan Kehoe]

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

 > >>>>> In <87hc45o6ea.fsf@marauder.physik.uni-ulm.de>
 > >>>>>	Reiner Steib <reinersteib+gmane@imap.cc> wrote:
 > > On Sun, Jan 11 2009, Aidan Kehoe wrote:
 > 
 > > > Sehr geehrte Damen und Herren!
 > 
 > > Since all of the recent matches for nnmail-pathname-coding-system in
 > > ChangeLog point to Katsumi Yamaoka, a Japanese greeting would be more
 > > appropriate.  ;-)
 > 
 > I'll look into it tomorrow.  Sorry I have no time today.  Anyway
 > those `file-name-coding-system' uses are for files used of
 > non-ASCII group names.  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? 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. 

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

 > > > Why is Gnus overriding file-name-coding-system? For example, in
 > > > nnmh-active-number, and pretty much everywhere that
 > > > nnmail-pathname-coding-system is used. In XEmacs 21.5 we have stupid hackery
 > > > that maintains the file-name coding system alias as equivalent to the
 > > > file-name-coding-system variable, but this doesn’t know about dynamic scope,
 > > > so after I’ve used Gnus my file-name-coding-system is reset to binary, which
 > > > is useless on OS X. If you’re using anything non-ASCII I imagine it’ll break
 > > > under Gnus too, and if you’re not using anything non-ASCII, why bother
 > > > messing with the variable at all?
 > > [...]
 > > > Gnus v5.10.8
 > > > XEmacs 21.5  (beta28) "fuki" 302136a857ec+ [Lucid] (i386-apple-darwin8.11.1, Mule) of Sat Jan 10 2009 on bonbon

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

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

[Katsumi Yamaoka]

>>>>> 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,

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

[Aidan Kehoe]

 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?

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

[Katsumi Yamaoka]

>>>>> 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,

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

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

>>>>> Katsumi Yamaoka wrote:
> 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.

[...]

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

I realized there is no difference in XEmacs 21.4.  What I tried
is attached below.

BTW, does this workaround do the trick?

(if (featurep 'xemacs)
    (if (featurep 'file-coding)
	(setq file-name-coding-system
	      (or file-name-coding-system
		  (coding-system-name 'file-name)))))

;; `(if (featurep 'xemacs) ...)' is a compiler directive for
;; letting GNU Emacs generate no byte code.

After performing it, XEmacs at least in Linux box seems to
run with no problem as follows:

--8<---------------cut here---------------start------------->8---
(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 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 utf-8 unicode(utf-8)>
--8<---------------cut here---------------end--------------->8---

If it's ok in OS X, I wish XEmacs itself to do something similar.
But it might be necessary to be in `gnus-xmas-redefine' in
gnus-xmas.el (nnmail.el loads it) for those who use old XEmacs.
For the latter case, it has to be guaranteed that the workaround
does no harm even in the distant future.

Regards,

[-- Attachment #2: Type: application/octet-stream, Size: 520 bytes --]

emacs-version
 => "21.4 (patch 22) \"Instant Classic\" XEmacs Lucid"

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

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

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

(get-coding-system 'file-name)
 => #<coding_system binary>

(define-coding-system-alias 'file-name 'iso-2022-jp)
 => nil

file-name-coding-system
 => nil

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

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

(get-coding-system 'file-name)
 => #<coding_system binary>

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

[Aidan Kehoe]

 Ar an ceathrú lá déag de mí Eanair, scríobh Katsumi Yamaoka: 
 > > 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.)

With the important difference that it can encode everything, so there’s no
need to play around with differing file-name-coding-systems for differing
parts of the file hierarchy, the data won’t be trashed. 

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

I made this change yesterday to do that: 

http://hg.debian.org/hg/xemacs/xemacs?cs=774e5c7522bf

This version of your macro works with versions of 21.5 both with and without
that patch, and with 21.4: 

(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)
      `(progn
        (when (featurep 'file-coding)
          ;; Work around a bug in many 21.5 betas:
          (setq file-name-coding-system (coding-system-aliasee
                                         'file-name)))
        (let ((file-name-coding-system
               nnmail-pathname-coding-system))
          ,@forms))
    `(let ((file-name-coding-system nnmail-pathname-coding-system))
       ,@forms)))

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

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

[Reiner Steib]

On Wed, Jan 14 2009, Aidan Kehoe wrote:

> I made this change yesterday to do that: 
>
> http://hg.debian.org/hg/xemacs/xemacs?cs=774e5c7522bf
>
> This version of your macro works with versions of 21.5 both with and without
> that patch, and with 21.4: 
>
> (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)
>       `(progn
>         (when (featurep 'file-coding)
>           ;; Work around a bug in many 21.5 betas:
>           (setq file-name-coding-system (coding-system-aliasee
>                                          'file-name)))

I didn't follow the thread carefully.  Do I understand correctly, that
the problem was a bug that is/was present only in XEmacs 21.5?

>         (let ((file-name-coding-system
>                nnmail-pathname-coding-system))
>           ,@forms))
>     `(let ((file-name-coding-system nnmail-pathname-coding-system))
>        ,@forms)))

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

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

[Aidan Kehoe]

 Ar an ceathrú lá déag de mí Eanair, scríobh Reiner Steib: 

 > On Wed, Jan 14 2009, Aidan Kehoe wrote:
 > 
 > > I made this change yesterday to do that: 
 > >
 > > http://hg.debian.org/hg/xemacs/xemacs?cs=774e5c7522bf
 > >
 > > This version of your macro works with versions of 21.5 both with and
 > > without that patch, and with 21.4:
 > >
 > > (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)
 > >       `(progn
 > >         (when (featurep 'file-coding)
 > >           ;; Work around a bug in many 21.5 betas:
 > >           (setq file-name-coding-system (coding-system-aliasee
 > >                                          'file-name)))
 > 
 > I didn't follow the thread carefully.  Do I understand correctly, that
 > the problem was a bug that is/was present only in XEmacs 21.5?

Well. I don’t think much of the nnmail-pathname-coding-system idea, from my
perspective it in itself is a bug, it should not be overriding
file-name-coding-system. It is not being a very good citizen to use
non-standard encoding for path names in a given directory without very good
reason. It does not look like Yamaoka is going to come around to that
perspective, though.

With the change to the XEmacs 21.5 sources above, the consequences of the
use of nnmail-pathname-coding-system are not as serious as they used to be,
for non-Gnus code; the consequences of the use of
nnmail-pathname-coding-system remain as bad as they used to be for the Gnus
code, because since nnmail-pathname-coding-system is normally nil, the
binary coding system will be used for all file names corresponding to group
names.

With the macro as proposed, Gnus users on beta XEmacs will no longer see the
consequences of the use of nnmail-pathname-coding-system for non-Gnus code.

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

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

[Katsumi Yamaoka]

>>>>> Aidan Kehoe <kehoea@parhasard.net> wrote:
> I made this change yesterday to do that:

> http://hg.debian.org/hg/xemacs/xemacs?cs=774e5c7522bf
--8<---------------cut here---------------start------------->8---
--- a/lisp/mule/mule-cmds.el    Sun Jan 11 13:18:42 2009 +0000
+++ b/lisp/mule/mule-cmds.el    Tue Jan 13 12:07:27 2009 +0000
[...]
-      (define-coding-system-alias 'file-name 
[...]
+      ;; These variables have magic handlers to make setting them equivalent
+      ;; to setting the file-name, terminal and keyboard coding system
+      ;; aliases. See coding.el. 
+      (setq file-name-coding-system 
+            (or 
+             (let ((fncs (assq system-type system-type-file-name-coding)))
+               (and fncs (cdr fncs)))
+             native)
--8<---------------cut here---------------end--------------->8---

> This version of your macro works with versions of 21.5 both with and without
> that patch, and with 21.4:

> (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)
>       `(progn
>         (when (featurep 'file-coding)
>           ;; Work around a bug in many 21.5 betas:
>           (setq file-name-coding-system (coding-system-aliasee
>                                          'file-name)))
>         (let ((file-name-coding-system
>                nnmail-pathname-coding-system))
>           ,@forms))
>     `(let ((file-name-coding-system nnmail-pathname-coding-system))
>        ,@forms)))

IIUC `(setq file-name-coding-system ...)' here is for XEmacs 21.5
to which your patch has not been applied yet.  Is it necessary to
do that in advance whenever one binds `file-name-coding-system' to
something?  In other words, supposing `file-name' will not vary
after having been set to a certain value according to the system,
isn't it enough to do it once when XEmacs starts?  That is,

>>>>> In <b4mtz82duj7.fsf@jpl.org> Katsumi Yamaoka wrote:
> BTW, does this workaround do the trick?

> (if (featurep 'xemacs)
>     (if (featurep 'file-coding)
> 	(setq file-name-coding-system
> 	      (or file-name-coding-system
> 		  (coding-system-name 'file-name)))))

I planned to introduce such a wrapper, however there are many
places that need it in Gnus:

$ grep '(file-name-coding-system' *.el | wc -l
88

So, I'd like to use a much simpler way to fix the problem if
possible.  Note that the Gnus release (i.e. the Emacs 23 release)
is around the corner.

Regards,

P.S. I wonder why this is brought up now although binding of
pathname-coding-system (the predecessor of file-name-coding-system)
appeared first in Quassia Gnus v0.1 (1997). ;-)

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

[Aidan Kehoe]

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

 > [...] IIUC `(setq file-name-coding-system ...)' here is for XEmacs 21.5
 > to which your patch has not been applied yet. Is it necessary to do that
 > in advance whenever one binds `file-name-coding-system' to something? In
 > other words, supposing `file-name' will not vary after having been set to
 > a certain value according to the system, isn't it enough to do it once
 > when XEmacs starts?

Once should be okay, yes. 

 > That is,
 > 
 > >>>>> In <b4mtz82duj7.fsf@jpl.org> Katsumi Yamaoka wrote:
 > > BTW, does this workaround do the trick?
 > 
 > > (if (featurep 'xemacs)
 > >     (if (featurep 'file-coding)
 > > 	(setq file-name-coding-system
 > > 	      (or file-name-coding-system
 > > 		  (coding-system-name 'file-name)))))

No, you want:

 (setq file-name-coding-system (coding-system-aliasee 'file-name))

 > I planned to introduce such a wrapper, however there are many
 > places that need it in Gnus:
 > 
 > $ grep '(file-name-coding-system' *.el | wc -l
 > 88
 > 
 > So, I'd like to use a much simpler way to fix the problem if
 > possible.  Note that the Gnus release (i.e. the Emacs 23 release)
 > is around the corner.
 > 
 > Regards,
 > 
 > P.S. I wonder why this is brought up now although binding of
 > pathname-coding-system (the predecessor of file-name-coding-system)
 > appeared first in Quassia Gnus v0.1 (1997). ;-)

I reported the bug because I recently learned a debugging technique which
discovering what went wrong much, much easier.

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

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

[Katsumi Yamaoka]

>>>>> Aidan Kehoe wrote:
>  Ar an cúigiú lá déag de mí Eanair, scríobh Katsumi Yamaoka:
>> In other words, supposing `file-name' will not vary after having
>> been set to a certain value according to the system, isn't it
>> enough to do it once when XEmacs starts?

> Once should be okay, yes.

>>> (if (featurep 'xemacs)
>>>     (if (featurep 'file-coding)
>>> 	(setq file-name-coding-system
>>> 	      (or file-name-coding-system
>>> 		  (coding-system-name 'file-name)))))

> No, you want:

>  (setq file-name-coding-system (coding-system-aliasee 'file-name))

I've installed this workaround in nnmail.el in No Gnus as follows:

(defvar nnmail-pathname-coding-system
  ;; This causes Emacs 22.2 and 22.3 to issue a useless warning.
  ;;(if (and (featurep 'xemacs) (featurep 'file-coding))
  (if (featurep 'xemacs)
      (if (featurep 'file-coding)
	  ;; Work around a bug in many XEmacs 21.5 betas.
	  ;; Cf. http://thread.gmane.org/gmane.emacs.gnus.general/68134
	  (setq file-name-coding-system (coding-system-aliasee 'file-name))))
  "*Coding system for file name.")

I concluded it's better to be in Gnus (and none other) which
necessarily uses binding of `file-name-coding-system'.  By this
change XEmacs users ought to have gotten not to have to customize
this variable if the default value satisfies encoding of all
non-ASCII group names.  Also I've updated the Gnus Info manual.

Cf. http://article.gmane.org/gmane.emacs.gnus.commits/6138
and http://article.gmane.org/gmane.emacs.gnus.commits/6139

Regards,

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

[Aidan Kehoe]

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

 > I've installed this workaround in nnmail.el in No Gnus as follows:

Thanks!

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

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

[Aidan Kehoe]

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

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

Note this, though: 

(emacs-version)
=> "GNU Emacs 23.0.60.1 (i386-apple-darwin8.11.1, NS apple-appkit-824.48)
 of 2008-12-27 on bonbon"
(coding-system-p nil)
=> t
(coding-system-get nil :name)
=> no-conversion

And this: 

(emacs-version)
=> "GNU Emacs 21.2.1 (powerpc-apple-darwin8.0)
 of 2008-12-22 on bonbon"

(coding-system-p nil)
=> t

(encode-coding-string "a b c ä" nil)
=> "a b c ä"


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