From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/68148 Path: news.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.gnus.general Subject: Re: nnmail-pathname-coding-system breaks my XEmacs. Date: Tue, 13 Jan 2009 15:46:52 +0900 Organization: Emacsen advocacy group Message-ID: 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=us-ascii X-Trace: ger.gmane.org 1231829320 19366 80.91.229.12 (13 Jan 2009 06:48:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Jan 2009 06:48:40 +0000 (UTC) Cc: ding@gnus.org To: Aidan Kehoe Original-X-From: ding-owner+M16592@lists.math.uh.edu Tue Jan 13 07:49:52 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 1LMd5z-0004iZ-6K for ding-account@gmane.org; Tue, 13 Jan 2009 07:49:51 +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 1LMd3s-0002oS-Gg; Tue, 13 Jan 2009 00:47:40 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LMd3o-0002o6-JK for ding@lists.math.uh.edu; Tue, 13 Jan 2009 00:47:36 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1LMd3l-0007T5-59 for ding@lists.math.uh.edu; Tue, 13 Jan 2009 00:47:36 -0600 Original-Received: from orlando.hostforweb.net ([216.246.45.90]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1LMd41-0004oe-00 for ; Tue, 13 Jan 2009 07:47:50 +0100 Original-Received: from localhost ([127.0.0.1]:39739) by orlando.hostforweb.net with esmtpa (Exim 4.69) (envelope-from ) id 1LMd2c-0003Gl-Hu; Tue, 13 Jan 2009 00:46:22 -0600 X-Hashcash: 1:20:090113:kehoea@parhasard.net::u8+mZZ24fOgBZ8Fi:000000000000000000000000000000000000000005LrL X-Hashcash: 1:20:090113:ding@gnus.org::juHviK1I450aVPP1:00000P01 X-Face: #kKnN,xUnmKia.'[pp`;Omh}odZK)?7wQSl"4o04=EixTF+V[""w~iNbM9ZL+.b*_CxUmFk B#Fu[*?MZZH@IkN:!"\w%I_zt>[$nm7nQosZ<3eu;B:$Q_:p!',P.c0-_Cy[dz4oIpw0ESA^D*1Lw= L&i*6&( User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:B7MGKoqkoKO4IFl5E7TzZdmyOpk= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - orlando.hostforweb.net X-AntiAbuse: Original Domain - gnus.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jpl.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.6 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:68148 Archived-At: >>>>> Aidan Kehoe 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,