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

[Aidan Kehoe <kehoea@parhasard.net>]

 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?