From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/63769 Path: news.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.gnus.general Subject: Re: mm-coding-system-priorities per hierarchy Date: Mon, 25 Sep 2006 20:36:54 +0900 Organization: Emacsen advocacy group Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Trace: sea.gmane.org 1159184910 2844 80.91.229.2 (25 Sep 2006 11:48:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Sep 2006 11:48:30 +0000 (UTC) Original-X-From: ding-owner+m12296@lists.math.uh.edu Mon Sep 25 13:48:25 2006 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GRowQ-00044o-Ew for ding-account@gmane.org; Mon, 25 Sep 2006 13:48:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1GRow7-0005IS-00; Mon, 25 Sep 2006 06:47:47 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1GRolw-0005IM-00 for ding@lists.math.uh.edu; Mon, 25 Sep 2006 06:37:16 -0500 Original-Received: from quimby.gnus.org ([80.91.227.211]) by mx1.math.uh.edu with esmtp (Exim 4.52) id 1GRolq-0000Fj-0b for ding@lists.math.uh.edu; Mon, 25 Sep 2006 06:37:16 -0500 Original-Received: from washington.hostforweb.net ([66.225.201.13]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1GRolf-0008U4-00 for ; Mon, 25 Sep 2006 13:36:59 +0200 Original-Received: from [205.234.185.198] (port=51025 helo=mail.jpl.org) by washington.hostforweb.net with esmtpa (Exim 4.52) id 1GRoly-0006Jw-Kr for ding@gnus.org; Mon, 25 Sep 2006 06:37:18 -0500 Original-To: ding@gnus.org X-Hashcash: 1:20:060925:ding@gnus.org::5rYkEGIcriesVNOL:00001H36 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.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:6M1+dpUyAYP0I32S8dUU/qtpkNQ= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - washington.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 (--) Precedence: bulk Original-Sender: ding-owner@lists.math.uh.edu Xref: news.gmane.org gmane.emacs.gnus.general:63769 Archived-At: >>>>> In >>>>> Reiner Steib wrote: > On Fri, Sep 22 2006, Katsumi Yamaoka wrote: >>>>>>> Reiner Steib wrote: >>> When using this expression... >> >>> (add-to-list 'gnus-newsgroup-variables 'mm-coding-system-priorities) >> >>> ... `gnus-summary-make-local-variables' sets the global value of >>> `mm-coding-system-priorities' to nil. I'd guess nil leads to utf-8 >>> instead of iso-2022-jp in your environment. >> >> No, it is not caused by the nil value. > IIRC, if `mm-coding-system-priorities' is nil, Gnus uses Emacs' > `sort-coding-systems' to find the suitable charset. So my guess was > that utf-8 is preferred to iso-2022-jp... Yes, you're right in the generality of cases. I'm sorry I forgot to mention that I use the ja_JP.eucjp locale (I use it to keep the compatibility with the old programs even though the recent Linux system uses ja_JP.utf8 by default). In that case, euc-jp is preferred to iso-2022-jp and utf-8. So, utf-8 should never be chosen to encode non-special Japanese text if `mm-coding-system-priorities' is nil. Here are examples observed in my Linux system: (mapcar 'symbol-value coding-category-list) => (japanese-iso-8bit iso-2022-jp japanese-shift-jis iso-2022-jp-2 iso-latin-1 mule-utf-8 mule-utf-16be-with-signature mule-utf-16le-with-signature iso-2022-7bit iso-2022-8bit-ss2 emacs-mule raw-text chinese-big5 nil no-conversion) (with-temp-buffer (insert "日本語") (let ((mm-coding-system-priorities nil)) (mm-find-mime-charset-region (point-min) (point-max)))) => (euc-jp) (with-temp-buffer (insert "日本語") (let ((mm-coding-system-priorities '(iso-8859-1 iso-8859-15 utf-8))) (mm-find-mime-charset-region (point-min) (point-max)))) => (utf-8) >>> Do you get the expected behavior with this expression? >> >>> (add-to-list 'gnus-newsgroup-variables >>> '(mm-coding-system-priorities . global)) >> >> That is not good for me. It should be the following: >> >> (add-to-list >> 'gnus-newsgroup-variables >> '(mm-coding-system-priorities >> . '(iso-8859-1 iso-2022-jp iso-2022-jp-2 shift_jis utf-8))) >> >> The value here is the default value of `mm-coding-system-priorities' >> in the Japanese language environment. > My understanding is that `global' is supposed to take this value. In the case where I use `global', `mm-coding-system-priorities' is changed into (iso-8859-1 iso-8859-15 utf-8) if I enter to a DE group even once, and it is unchanged after I exit the group. In other words, the `global' value is changed into (iso-8859-1 iso-8859-15 utf-8). There is no means to save the initial (global) value. So, it keeps the value suitable to DE groups even if I enter for the next time to a group that is not listed in `gnus-parameters'. > Is it a bug (in gnus-sum.el) or am I missing something? I'm not quite sure of it but it might be a bug in the sense that the global value is not always the initial value. [...] >> What I'd like to say is that a similar problem will probably >> happen with people who are not in the Japanes language >> environment as well. Group parameter is useful to things >> associated to group, however messages are not always associated >> to group. > I think it is (also?) a bug if entering a group modifies the > default-value of a variable. It probably should only modify the local > values in the summary, article and message buffers for the matching > groups. Well, I think it will not go well. The values specific to the group that is currently focused by a user should be seen in any buffers (except for the other summary buffers which visit the other groups). It is because a program which works for an article or a summary associated with the group might run in a temp buffer, a process buffer, etc. > The code of `gnus-summary-make-local-variables' seems to be correct. > Maybe `gnus-set-global-variables' or some other function is the > culprit? I think the group parameter was designed for reading articles and displaying summaries but did not intend to use with messages to send (though it is actually useful only for sending messages to the current newsgroup). The other framework will be necessary. It reads Newsgroups header, To header, etc. in a message buffer and decides what to do. Regards,