From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/68151 Path: news.gmane.org!not-for-mail From: Aidan Kehoe Newsgroups: gmane.emacs.gnus.general Subject: Re: nnmail-pathname-coding-system breaks my XEmacs. Date: Tue, 13 Jan 2009 12:02:36 +0000 Message-ID: <18796.33500.65305.970938@parhasard.net> References: <18794.15468.881403.994781@parhasard.net> <87hc45o6ea.fsf@marauder.physik.uni-ulm.de> <18795.12614.222792.255516@parhasard.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1231848231 12722 80.91.229.12 (13 Jan 2009 12:03:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Jan 2009 12:03:51 +0000 (UTC) Cc: ding@gnus.org To: Katsumi Yamaoka Original-X-From: ding-owner+M16595@lists.math.uh.edu Tue Jan 13 13:05:02 2009 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1LMi0v-000872-2r for ding-account@gmane.org; Tue, 13 Jan 2009 13:04:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1LMhz4-0004V2-PA; Tue, 13 Jan 2009 06:03:02 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LMhz3-0004Ub-0K for ding@lists.math.uh.edu; Tue, 13 Jan 2009 06:03:01 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1LMhyy-0007NQ-KK for ding@lists.math.uh.edu; Tue, 13 Jan 2009 06:03:00 -0600 Original-Received: from daedalus.ipv4.asclepian.ie ([213.133.100.226] helo=daedalus.asclepian.ie) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1LMhzF-0000RA-00 for ; Tue, 13 Jan 2009 13:03:13 +0100 Original-Received: by daedalus.asclepian.ie (Postfix, from userid 1002) id 33814B816; Tue, 13 Jan 2009 12:02:36 +0000 (GMT) In-Reply-To: X-Mailer: VM 8.0.12 under 21.5 (beta28) "fuki" XEmacs Lucid (x86_64-unknown-freebsd7.0) X-Echelon-distraction: SGC Delta Force NTT NCSA CBNRC NIJ X-Spam-Score: -2.6 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:68151 Archived-At: Ar an tri=C3=BA l=C3=A1 d=C3=A9ag de m=C3=AD Eanair, scr=C3=ADobh Katsum= i Yamaoka:=20 > 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=E2=80=99t vary remotely as much on= a single system as can file content encodings. And dynamic let bindings can be use= d 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=E2=80=99t 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. >=20 > (Especially for testing Gnus, I subscribe to many non-ASCII > groups even if I'm not capable to read all of those languages.) >=20 > 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',=20 UTF-8 is *enforced* on OS X, in contrast to most Unix environments.=20 > and Emacs 21, XEmacs 21.4 and SXEmacs don't support `utf-8' fully (eve= n > if the Mule-UCS package is loaded). >=20 > 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. >=20 > > 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. >=20 > So, how about changing the `let' bindings here and there in this > way? >=20 > (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 earl= ier mail it will break file-name-coding-system if a user actually uses use nnmail-pathname-coding-system binding, but that=E2=80=99s a slightly bett= er situation than the current one, where file-name-coding-system is broken afterwards whether the user uses nnmail-pathname-coding-system or not.=20 > [...] 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' t= o > nil for the "ja_JP.UTF-8" locale, though. Yes, that=E2=80=99s a cosmetic bug on our part. The file-name coding syst= em alias, which is actually what=E2=80=99s used in the C code, is supposed to be eq= uivalent to the file-name-coding-system variable, but I hadn=E2=80=99t maintained thi= s relationship in writing the startup code. I=E2=80=99ll fix that.=20 Try LC_CTYPE=3Dja_JP.UTF-8 xemacs-21.5-b28 -batch -eval "(princ (coding-syste= m-aliasee 'file-name))" if you want to check that.=20 > > (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.) >=20 > 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=E2=80=99t know why that decision was made. --=20 =C2=BFD=C3=B3nde estar=C3=A1 ahora mi sobrino Yoghurtu Nghe, que tuvo que= huir precipitadamente de la aldea por culpa de la escasez de rinocerontes?