From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/68157 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: Wed, 14 Jan 2009 15:36:13 +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> <18796.33500.65305.970938@parhasard.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1231915271 2746 80.91.229.12 (14 Jan 2009 06:41:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Jan 2009 06:41:11 +0000 (UTC) Cc: ding@gnus.org To: Aidan Kehoe Original-X-From: ding-owner+M16601@lists.math.uh.edu Wed Jan 14 07:42:23 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 1LMzSH-0003ya-3E for ding-account@gmane.org; Wed, 14 Jan 2009 07:42:21 +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 1LMzQ4-0001O8-FL; Wed, 14 Jan 2009 00:40:04 -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 1LMzN7-0001Mz-0i for ding@lists.math.uh.edu; Wed, 14 Jan 2009 00:37:01 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1LMzN3-0004s2-OV for ding@lists.math.uh.edu; Wed, 14 Jan 2009 00:37:00 -0600 Original-Received: from orlando.hostforweb.net ([216.246.45.90]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1LMzNK-0005oq-00 for ; Wed, 14 Jan 2009 07:37:14 +0100 Original-Received: from localhost ([127.0.0.1]:43554) by orlando.hostforweb.net with esmtpa (Exim 4.69) (envelope-from ) id 1LMzMS-0006sq-TN; Wed, 14 Jan 2009 00:36:21 -0600 X-Hashcash: 1:20:090114:kehoea@parhasard.net::8nyWyyHtJb/0rsd5:000000000000000000000000000000000000000007ATL X-Hashcash: 1:20:090114:ding@gnus.org::aGxzUFZd2eG+9Gq8:0000AD9J 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:WffFT/mo2v4oKUEWqO6DapsRIGY= 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:68157 Archived-At: >>>>> 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) => # (let ((file-name-coding-system nil))) => nil (get-coding-system 'file-name) => # --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) => # (let ((file-name-coding-system 'iso-2022-jp)) (get-coding-system 'file-name)) => # # --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) => # (let ((file-name-coding-system nil))) => nil (get-coding-system 'file-name) => # (let ((file-name-coding-system 'euc-jp)) (get-coding-system 'file-name)) => # (get-coding-system 'file-name) => # --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,