From: Shenghuo ZHU <zsh@cs.rochester.edu>
Subject: nndraft encode/decode
Date: 23 Jun 1999 19:16:09 -0400 [thread overview]
Message-ID: <2nn1xqzex2.fsf@zsh.cs.rochester.edu> (raw)
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
reply other threads:[~1999-06-23 23:16 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2nn1xqzex2.fsf@zsh.cs.rochester.edu \
--to=zsh@cs.rochester.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).