sending delayed articles bug

sending delayed articles bug

[Katsumi Yamaoka]

Hi,

Someone found a bug while using the gnus-delay feature that
delayed articles won't be MIME encoded even if they contain
Japanese text.  I've fixed it.

The function nndraft-request-article used the coding-system
emacs-mule or escape-quoted for reading articles from the
nndraft:drafts group but raw-text for the nndraft:delayed group.
However, the coding-system raw-text is for queued articles.
Therefore, especially in FSF Emacs, broken mails have been sent.
I've made the function use emacs-mule or escape-quoted even for
delayed articles.

By the way, why don't we use the universal coding-system, e.g.
iso-2022-7-bit, for saving and reading draft articles in both
FSF Emacs and XEmacs?  In the present, FSF Emacs uses emacs-mule
and XEmacs uses escape-quoted by default, so draft articles made
by FSF Emacs can't be handled by XEmacs and the contrary is also
bad. :-{
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: sending delayed articles bug

[Kai Großjohann]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> By the way, why don't we use the universal coding-system, e.g.
> iso-2022-7-bit, for saving and reading draft articles in both
> FSF Emacs and XEmacs?  In the present, FSF Emacs uses emacs-mule
> and XEmacs uses escape-quoted by default, so draft articles made
> by FSF Emacs can't be handled by XEmacs and the contrary is also
> bad. :-{

That's a good idea!

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

coding-system for drafts (was Re: sending delayed articles bug)

[Katsumi Yamaoka]

Hi,

If you have unfinished drafts, I recommend you send all of them
before updating Gnus.  I took care you don't have to do so,
though. :)

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

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

>> By the way, why don't we use the universal coding-system, e.g.
>> iso-2022-7-bit, for saving and reading draft articles in both
>> FSF Emacs and XEmacs?  In the present, FSF Emacs uses emacs-mule
>> and XEmacs uses escape-quoted by default, so draft articles made
>> by FSF Emacs can't be handled by XEmacs and the contrary is also
>> bad. :-{

> That's a good idea!

Thanks.

Let's put a point at issue into the handling of the existing
draft files.  First of all, there's no problem if a user has set
mm-auto-save-coding-system to a certain value.  It is
satisfactory for using iso-2022-7bit to read draft files which
have been saved by escape-quoted either, since those coding
systems are mostly compatible under XEmacs.  However, a relief
measure should be taken in the case of FSF Emacs.  Then, I've
changed mm-util.el and nndraft.el with the following plans:

1. Set the default value for mm-auto-save-coding-system to
   iso-2022-7bit, except nil for non-Mule XEmacs.  The value is
   passed to message-draft-coding-system.

2. Simply read a draft file using the value of
   message-draft-coding-system under XEmacs.

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.

I wish there were no problems.

Regards,
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: coding-system for drafts

[Kai Großjohann]

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.

And then, you could write the encoding of the draft into a header.
Then a missing header means to do what has been done up to now so we
stay backwards compatible.  WDYT?

kai (not an expert on Mule)
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: coding-system for drafts

[Katsumi Yamaoka]

>>>>> 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>

Re: coding-system for drafts

[Kai Großjohann]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> 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?

Why do you have to read a draft twice?  If you design the coding
cookie ingeniously, then you won't need to do that.

You can put

X-Gnus-Coding: -*- coding: frumple -*-

as the first header.  Then the Emacs machinery will take care of
automatically selecting the frumple coding for reading the file.
However, the above MUST be the first line in the file.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: coding-system for drafts

[Katsumi Yamaoka]

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

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

>> We have to read a draft file twice, however large a file may be.

> Why do you have to read a draft twice?  If you design the coding
> cookie ingeniously, then you won't need to do that.

> You can put

> X-Gnus-Coding: -*- coding: frumple -*-

> as the first header.  Then the Emacs machinery will take care of
> automatically selecting the frumple coding for reading the file.
> However, the above MUST be the first line in the file.

I see.  That's a good idea.  Perhaps we can abolish the variable
mm-auto-save-coding-system and set the default value for
message-draft-coding-system to frumple (or iso-2022-7bit).

Since not to bind the value for coding-system-for-read is
required to utilize that function, what should we do if there is
no such header?  Or isn't there nothing to do?

In addition, it is required that the coding header should be
untouchable by a user.  In order to ensure it, we will add the
header using write-contents-hooks and remove it before starting
edit of a draft.  Haven't I made a mistake in my idea?
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: coding-system for drafts

[Kai Großjohann]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> I see.  That's a good idea.  Perhaps we can abolish the variable
> mm-auto-save-coding-system and set the default value for
> message-draft-coding-system to frumple (or iso-2022-7bit).

Yes, maybe.  Hm.  Oh, yes, new auto-saves will always have the
cookie.  So no problem.

(But what happens for XEmacsen which do not interpret the cookie?
Are there such versions?)

> Since not to bind the value for coding-system-for-read is
> required to utilize that function, what should we do if there is
> no such header?  Or isn't there nothing to do?

Binding coding-system-for-read is not good because it takes
precedence over everything else.  But if we could find a way to
specify the coding system that has LOWER precedence than the coding
cookie, then we can do that.

Maybe it works via auto-coding-alist?  No, that takes precedence.  So
we should use file-coding-system-alist.  Do you think that might work?

> In addition, it is required that the coding header should be
> untouchable by a user.  In order to ensure it, we will add the
> header using write-contents-hooks and remove it before starting
> edit of a draft.  Haven't I made a mistake in my idea?

That would work.

Another idea is to narrow the buffer so that point-min is after the
header.  But that might be more fragile.

Does auto-saving run write-contents-hooks?

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: coding-system for drafts

[Katsumi Yamaoka]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 2504 bytes --]

>>>>> In <84znsv52f5.fsf@crybaby.uni-duisburg.de>
>>>>>	kai.grossjohann@uni-duisburg.de (Kai Gro^[.A^[N_johann) wrote:

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

>> I see.  That's a good idea.  Perhaps we can abolish the variable
>> mm-auto-save-coding-system and set the default value for
>> message-draft-coding-system to frumple (or iso-2022-7bit).

> Yes, maybe.  Hm.  Oh, yes, new auto-saves will always have the
> cookie.  So no problem.

> (But what happens for XEmacsen which do not interpret the cookie?
> Are there such versions?)

It works from the early stage of XEmacs 20 with Mule.  However,
I don't know about the recent XEmacs 21.5 beta (I'm discouraged,
it is something broken in the coding-system handling).

>> Since not to bind the value for coding-system-for-read is
>> required to utilize that function, what should we do if there is
>> no such header?  Or isn't there nothing to do?

> Binding coding-system-for-read is not good because it takes
> precedence over everything else.  But if we could find a way to
> specify the coding system that has LOWER precedence than the coding
> cookie, then we can do that.

> Maybe it works via auto-coding-alist?  No, that takes precedence.  So
> we should use file-coding-system-alist.  Do you think that might work?

I've confirmed that the following example works:

(let ((file-coding-system-alist
       (cons
	(cons (concat "\\`"
		      (regexp-quote (expand-file-name FILE))
		      "\\'")
	      'frumple)
	file-coding-system-alist))
      (nnmail-file-coding-system nil))
  (nnmail-find-file (expand-file-name FILE)))

We can also set the value for file-coding-system-alist rigidly.
However, I get confused.  Isn't there any difference in this and
the next example?

(let ((nnmail-file-coding-system 'frumple))
  (nnmail-find-file (expand-file-name FILE)))

>> In addition, it is required that the coding header should be
>> untouchable by a user.  In order to ensure it, we will add the
>> header using write-contents-hooks and remove it before starting
>> edit of a draft.  Haven't I made a mistake in my idea?

> That would work.

> Another idea is to narrow the buffer so that point-min is after the
> header.  But that might be more fragile.

Hm, each is hard to be called good idea.  The hidden area might
be exposed in the future like message-strip-forbidden-properties
does.

> Does auto-saving run write-contents-hooks?

I've confirmed no.  We have to use auto-save-hook together.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: coding-system for drafts

[Katsumi Yamaoka]

I supplement with the last message, since my strange English
might not have been understood.

>>>>> In <yotlznsvfc9i.fsf@jpl.org>
>>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:

>>> Since not to bind the value for coding-system-for-read is
>>> required to utilize that function, what should we do if there is
>>> no such header?  Or isn't there nothing to do?

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.

There is probably no problem when using the present source code.
However, we have to solve the above-mentioned problem before
implementing the coding header.  If a broken draft is appeared,
the majority of gentle people will accept that situation and
rewrite it, rest of people will tell us a complaint.  And such a
state will continue for a while.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: coding-system for drafts

[Kai Großjohann]

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 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?

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: coding-system for drafts

[Katsumi Yamaoka]

>>>>> 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>

Re: coding-system for drafts

[Kai Großjohann]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> 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.

I have now (finally!) looked at the code for nndraft-request-article.
It's very impressive.

I think the logic is this: if we are in Emacs (not XEmacs) and if the
message-draft-coding-system is iso-2022-7bit, then all bytes in the
file must be less than 128.  So if we find a byte larger than 128
then we guess it must have come from an old draft which has been
saved in emacs-mule.

But people who have configured message-draft-coding-system will
continue to have the same value, so the above condition is false, so
even people who have configured message-draft-coding-system will have
no problems.

People who want to change message-draft-coding-system should make
sure that they have no drafts when they do it :-)

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: coding-system for drafts

[Kai Großjohann]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

>>>>>> In <84znsv52f5.fsf@crybaby.uni-duisburg.de>
>>>>>>	kai.grossjohann@uni-duisburg.de (Kai Großjohann) wrote:
>
> I've confirmed that the following example works:
>
> (let ((file-coding-system-alist
>        (cons
> 	(cons (concat "\\`"
> 		      (regexp-quote (expand-file-name FILE))
> 		      "\\'")
> 	      'frumple)
> 	file-coding-system-alist))
>       (nnmail-file-coding-system nil))
>   (nnmail-find-file (expand-file-name FILE)))
>
> We can also set the value for file-coding-system-alist rigidly.
> However, I get confused.  Isn't there any difference in this and
> the next example?
>
> (let ((nnmail-file-coding-system 'frumple))
>   (nnmail-find-file (expand-file-name FILE)))

I would guess they are the same.

>> Another idea is to narrow the buffer so that point-min is after the
>> header.  But that might be more fragile.
>
> Hm, each is hard to be called good idea.  The hidden area might
> be exposed in the future like message-strip-forbidden-properties
> does.

Narrowing does not use text properties.  But maybe one of the (widen)
statements in message.el breaks things.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: coding-system for drafts

[Kai Großjohann]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> I would guess they are the same.

But it's clear that you know much better than me what is going on!

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: coding-system for drafts

[Katsumi Yamaoka]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 686 bytes --]

>>>>> In <84d6ppnptd.fsf@crybaby.uni-duisburg.de> 
>>>>>	kai.grossjohann@uni-duisburg.de (Kai Gro^[.A^[N_johann) wrote:

>> I would guess they are the same.

> But it's clear that you know much better than me what is going on!

As we don't grasp the behavior of Emacs to Latin characters
perfectly, I think the behavior to Japanese characters may have
not been understood as well.

By the way, I noticed that sent queued articles got broken, and
I've just fixed it.  Latin people may have not noticed that
problem. :-p

P.S. TSUCHIYA-san, thanks very much for the detailed description.
     It will surely be helpful to an East-West understanding.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: coding-system for drafts

[Kai Großjohann]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> P.S. TSUCHIYA-san, thanks very much for the detailed description.
>      It will surely be helpful to an East-West understanding.

Yes, indeed.

I apologize for being such a thickhead.  I should have taken the time
to properly understand your code.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: coding-system for drafts

[Katsumi Yamaoka]

Hello all,

Please ignore this article if you only use us-ascii characters
to write mail or news messages or you've customized the value of
`message-draft-coding-system' or `mm-auto-save-coding-system'.
Possibly you may also ignore this if you are using XEmacs only.

If you have unfinished draft articles or delayed articles which
has not been sent yet, I strongly recommend you send those
articles before updating Gnus.

I've restored the default value of `message-draft-coding-system'
to the old state as before October 29.  It is `emacs-mule' for
FSF Emacs or `escape-quoted' for XEmacs.  This is used for
saving draft files.

Once I've unified it into iso-2022-7bit regardless of the Emacs
version.  However, I was made to notice that iso-2022-7bit is
not suitable for all sorts of characters even if it is used for
the etc/HELLO file.  Though iso-2022-7bit can express almost all
characters, the default value should be strictly universal.  I
think customizing that value should be done at user's own risk.
It is a real disappointment that draft files can't be shared
with Emacs and XEmacs, though.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>

Re: coding-system for drafts

[Reiner Steib]

On Fri, Nov 08 2002, Katsumi Yamaoka wrote:

> If you have unfinished draft articles or delayed articles which
> has not been sent yet, I strongly recommend you send those
> articles before updating Gnus.
>
> I've restored the default value of `message-draft-coding-system'
> to the old state as before October 29.  It is `emacs-mule' for
> FSF Emacs or `escape-quoted' for XEmacs.  This is used for
> saving draft files.

I used the following to convert a bunch of drafts (from the
"iso-2022-7bit"-period) to the (restored) internal encoding.

(defun rs-gnus-draft-J-to-internal ()
  (interactive)
  (let* ((draft-coding message-draft-coding-system)
	 (message-draft-coding-system 'iso-2022-7bit))
    (gnus-draft-edit-message)
    (set-buffer-file-coding-system draft-coding)
    (setq message-draft-coding-system draft-coding)
    (message-dont-send)
    (gnus-summary-rescan-group t)))
(define-key gnus-draft-mode-map (kbd "D D") 'rs-gnus-draft-J-to-internal)

Just hit `D D' on each message you want to convert (don't use it on
drafts saved as `emacs-mule' or `escape-quoted'!). Please, feel free
to suggest a better solution.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: coding-system for drafts

[TSUCHIYA Masatoshi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 2652 bytes --]

>> On Tue, 29 Oct 2002 15:27:11 +0100
>> kai.grossjohann@uni-duisburg.de (Kai Gro^[.A^[N_johann) said as follows:

>> 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?

I think that his intention is to decode old drafts which were
genereted by old Gnusae safely.

>And then, you could write the encoding of the draft into a header.
>Then a missing header means to do what has been done up to now so we
>stay backwards compatible.

I think that your solution consists of two parts:

  (1) A new draft which has a coding cookie is decoded in the coding
      system specified in its cookie.
  (2) An old draft which lacks a coding cookie is decoded in the value
      of message-draft-coding-system.

In this solution, the default value of message-draft-coding-system
will be stayed in order to keep backwards compatibility.  Do I have a
proper understanding?

Mr. Yamaoka and I think that emacs-mule is not suitable for the
default value of message-draft-coding-system.  The main ground of our
argument is that emacs-mule is not compatible between emacsen.  For
example,

  (a) emacs-mule is not compatible between Emacs20 and Emacs21,
      because some charsets are supported by Emacs21 but are not
      supported by Emacs20.
  (b) emacs-mule is not compatible between Emacs20 with Mule-UCS and
      Emacs20 without Mule-UCS.  Charsets related to Unicode are not
      defined in Emacs20 without Mule-UCS.
  (c) Because XEmacs does not have emacs-mule coding system, drafts
      which are written under FSF Emacs are not readable with XEmacs.

Therefore, we think that it is necessary to change the default value
of message-draft-coding-system from emacs-mule to a coding system
which is compatible between emacsen and can be used to encode
multilingual text safely, such as iso-2022-7bit.

Unfortunately, once the default value of message-draft-coding-system
is changed to iso-2022-7bit, old drafts encoded in emacs-mule will not
be decoded correctly.  The trick described by Mr. Yamaoka is designed
to solve this problem.  Could you tell me how coding cookie solves
this problem?

It is true that we could safely change the default value of
message-draft-coding-system, if coding cookie was introduced.

-- 
TSUCHIYA Masatoshi

Re: coding-system for drafts

[Kai Großjohann]

TSUCHIYA Masatoshi <tsuchiya@namazu.org> writes:

> I think that your solution consists of two parts:
>
>   (1) A new draft which has a coding cookie is decoded in the coding
>       system specified in its cookie.
>   (2) An old draft which lacks a coding cookie is decoded in the value
>       of message-draft-coding-system.

That's right.  There is also the encoding part, though.  I don't have
an opinion which coding system should be used for new drafts (but the
safe iso-2022-7bit seems good), but whatever is chosen should be put
in the coding cookie so that subsequent readings of the file with do
the right thing.

> In this solution, the default value of message-draft-coding-system
> will be stayed in order to keep backwards compatibility.  Do I have a
> proper understanding?

Well, for new auto-save files a different encoding can be chosen.
Only the encoding for reading the old auto-save files must remain the
same.

Silly me, I thought that one could just hard-code `emacs-mule' as the
encoding for reading old files, but that would break if people have
changed message-draft-coding-system.  As you can see, I haven't
thought about it very thoroughly.

> Mr. Yamaoka and I think that emacs-mule is not suitable for the
> default value of message-draft-coding-system.  The main ground of our
> argument is that emacs-mule is not compatible between emacsen.  For
> example,
>
>   (a) emacs-mule is not compatible between Emacs20 and Emacs21,
>       because some charsets are supported by Emacs21 but are not
>       supported by Emacs20.
>   (b) emacs-mule is not compatible between Emacs20 with Mule-UCS and
>       Emacs20 without Mule-UCS.  Charsets related to Unicode are not
>       defined in Emacs20 without Mule-UCS.
>   (c) Because XEmacs does not have emacs-mule coding system, drafts
>       which are written under FSF Emacs are not readable with XEmacs.
>
> Therefore, we think that it is necessary to change the default value
> of message-draft-coding-system from emacs-mule to a coding system
> which is compatible between emacsen and can be used to encode
> multilingual text safely, such as iso-2022-7bit.

I agree that new files should be written using that encoding.

It does not mean that message-draft-coding-system must the variable to
do this.  Maybe we could make that variable obsolete and use a new
one.

> Unfortunately, once the default value of message-draft-coding-system
> is changed to iso-2022-7bit, old drafts encoded in emacs-mule will not
> be decoded correctly.  The trick described by Mr. Yamaoka is designed
> to solve this problem.

Right.  It's a good trick, I think.

Now I understand that we have been talking about different problems.
That explains our misunderstandings :-)

> Could you tell me how coding cookie solves this problem?

The coding cookie does not deal with old files, only with new files.
So the coding cookie is not a solution to the problem solved by
Yamaoka-san.

> It is true that we could safely change the default value of
> message-draft-coding-system, if coding cookie was introduced.

If it wasn't for the old files, we could...

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)