Re: coding-system for drafts

[Katsumi Yamaoka <yamaoka@jpl.org>]

>>>>> In <847kfyo6ja.fsf@crybaby.uni-duisburg.de>
>>>>>	kai.grossjohann@uni-duisburg.de (Kai Großjohann) wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> It is assumed that a draft file without the coding header has
>> been saved when message-draft-coding-system was emacs-mule.  Or
>> possibly it was something another.  But now it is iso-2022-7bit.
>> Though Emacs will do automatic decoding if coding-system-for-read
>> is bound to nil, it is not expected that it works correctly.

> But this was only changed a few days ago, right?  People who use the
> CVS source code will have to live with those kinds of problems, IMHO.

It is affirmative and also negative.  She won't be damaged if
she hasn't changed the variable message-draft-coding-system or
mm-auto-save-coding-system.  Could you please see my changes in
the function nndraft-request-article?  I think there are a few
people who has changed that value, and they seem to be
sophisticated users since those variables are not a user option.
Therefore,

> It is possible to make an announcement on this list to tell people
> that drafts saved after 29 Oct might have to be converted before
> using the new Gnus version.  Does it work to C-x C-f the file, change
> buffer-file-coding-system (with C-x RET f), then save the file?

I think we have no need to notify of it.  I wrote the code to
make an announcement unnecessary.  However, a situation will
change if we implement the way to use the coding cookie.  When
coding-system-for-read is unbound, a file name does not match
with file-coding-system-alist and there is no cookie (a file has
been saved in the past), Emacs will do the automatic decoding.
If a draft file has been saved as emacs-mule, although it may be
successful in Latin, it fails in Japanese certainly.  Did you
know?

To tell the truth, I don't yet understand the reason of
suffering to use the coding cookie.  Even if my code is not
elegant, it is another problem. :-p
-- 
Katsumi Yamaoka <yamaoka@jpl.org>