nndraft encode/decode

nndraft encode/decode

[Shenghuo ZHU]

1. Press 'm' to start composing a mail, and copy some Chinese
    or Japanese (from HELLO file) in the buffer.
2. Save it (C-x C-s). 
3. Go to nndraft:drafts, and edit it (D e). 

   In 0.88, the mail buffer contains encoded text. BUG!

Or  (when gnus-unplugged)
1. Press 'm' to start composing a mail, and copy some Chinese
    or Japanese (from HELLO file) in the buffer or attach something.
2. Send it (C-c C-c).
3. Go to nndraft:queue, and edit it (D e). 

   In 0.88, the mail buffer contains base64 encoded stuff, which is
   not suppose to be edited. BUG!

I find two suspicious modifications in ChangeLog.

,--------
| 1999-03-06 07:20:05  Lars Magne Ingebrigtsen  <larsi@gnus.org>
| 
| 	* nndraft.el (nndraft-request-article): Would clobber Japanese. 
|
| 1999-02-04 00:00:35  Lars Magne Ingebrigtsen  <larsi@gnus.org>
| 
| 	* gnus-sum.el (gnus-summary-setup-default-charset): Don't
| 	special-case nndraft groups.
`--------

These make 'nndraft:queue' work correctly, but at the same time, cause
trouble in 'nndraft:drafts'.  Actually, 'drafts' and 'queue' are
totally different in many features.

In 'drafts', everything is kept the same as those in a message buffer.

   1. When request-article an article, the article should be loaded
   with the coding system as it is saved
   (message-draft-coding-system), and should NOT be decoded later (in
   gnus-get-newsgroup-headers and gnus-request-article-this-buffer). I
   use a trick, setting gnus-newsgroup-charset to nil (in pgnus
   0.54-.75).

   2. When edit an article, the article should be 'restored' to the
   state of *message*

   3. When send, characters and MML should be encoded (A bug in 'D s'
   and I've sent a patch). I suggest a new backend function named
   nnoo-request-send.

In 'queue', articles are *encoded* (perhaps contain 8-bit characters
in some cases[1]). 

   1. When request-article and article, the backend should work like
   nnmh, i.e. the article should be decoded.

   2. When edit, the article should be 'restored'[1] as
   gnus-article-edit does. If save (C-x C-s), the article goes to
   nndraft:draft.

   3. When send, no encoding operation.

Therefore, queue is more like nnmh than nndraft.

[1] Coding-system causes gnus buggy. Here, I will say something about
coding-system used in gnus.

,-------- Code from nndraft.el
| 		 (let ((nnmail-file-coding-system
| 			(if (file-newer-than-file-p file auto)
| 			    'binary
| 			  message-draft-coding-system)))
| 		   (nnmail-find-file newest)))
`--------

In 'queue', coding-system-for-read is supposed to be binary.  Here are
some other coding-system

,--------
| (defvar nnmail-file-coding-system 'binary
|   "Coding system used in nnmail.")
| 
| (defvar nnmail-file-coding-system-1
|   (if (string-match "nt" system-configuration)
|       'raw-text-dos 'binary)
|   "Another coding system used in nnmail.")
| 
| (defvar nnheader-file-coding-system 'binary
|   "Coding system used in file backends of Gnus.")
| 
| (defvar gnus-agent-file-coding-system 'binary)
| 
| (defvar gnus-cache-coding-system 'binary
|   "Coding system used on Gnus cache files.")
| 
| (defvar score-mode-coding-system 'binary)
`--------

Most of them are binary.  Binary coding-system should work in Unix,
but in DOS, probable not. Actually, the article files (except drafts)
are text file (8-bit or not), because they have end-of-line. I suggest
these coding-system should be raw-text (or mm-text-coding-system for
compatible reason).

[2] The word 'restore' is from 'gnus-request-restore-buffer'. But I
think the document is not precise.  The function is supposed to
restore the article to the state of *message*, I guess. I suggest this
function to be extended to restore the article to the state of
*article edit* also, so that gnus-article-edit could use this function
to request an edit buffer.

,--------
| (gnus-request-restore-buffer ARTICLE GROUP)
| 
| Request a new buffer restored to the state of ARTICLE.
`--------

The last argument of gnus-request-replace-article should be
the-state-of-blah-blah instead of no-encode.

-- 
Shenghuo