Re: mm-coding-system-priorities per hierarchy

[Katsumi Yamaoka <yamaoka@jpl.org>]

>>>>> In <v9slihtn7g.fsf@marauder.physik.uni-ulm.de>
>>>>>	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,