Re: coding-system for drafts

[Katsumi Yamaoka <yamaoka@jpl.org>]

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