Re: coding-system for drafts

[Katsumi Yamaoka <yamaoka@jpl.org>]

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

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

>> 3. Under FSF Emacs, read a draft file as raw-text into a buffer
>>    if the value of message-draft-coding-system is iso-2022-7bit,
>>    otherwise use the value of message-draft-coding-system itself
>>    to read a file.  In the former case, decode the buffer
>>    contents as emacs-mule if there are over-7-bit data in a
>>    buffer, otherwise decode the contents using the value of
>>    message-draft-coding-system.

> Why can't you read a draft as iso-2022-7bit?  After all, that's the
> coding system that was used for saving it, too.

Yes, of course.  However, there might be draft files which have
been saved as emacs-mule before updating Gnus.  Those files
can't be read as iso-2022-7-bit.  Is it superfluous?

> And then, you could write the encoding of the draft into a header.

It's coincidence.  I got the same proposal from Daiki Ueno
before one month and a half.

> Then a missing header means to do what has been done up to now so we
> stay backwards compatible.  WDYT?

Although it is rational apparently, it takes efforts that:

We have to read a draft file twice, however large a file may be.
We should use a local-hook like write-contents-hooks for adding
an extra header, though it isn't difficult.  An extra header
should be deleted before sending.  Gnus can do it, don't other
programs use the same draft?

Since message-draft-coding-system is not a user option, I didn't
think we should do so.  And it is an important point, what
coding-system should we use for decoding when there is no extra
header?  After all, I think it is the same as the present way to
assume that it is emacs-mule.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>