From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/23502 Path: main.gmane.org!not-for-mail From: Shenghuo ZHU Newsgroups: gmane.emacs.gnus.general Subject: nndraft encode/decode Date: 23 Jun 1999 19:16:09 -0400 Organization: U of Rochester Sender: owner-ding@hpc.uh.edu Message-ID: <2nn1xqzex2.fsf@zsh.cs.rochester.edu> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035161223 2362 80.91.224.250 (21 Oct 2002 00:47:03 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 00:47:03 +0000 (UTC) Return-Path: Original-Received: from farabi.math.uh.edu (farabi.math.uh.edu [129.7.128.57]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id TAA19725 for ; Wed, 23 Jun 1999 19:14:33 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by farabi.math.uh.edu (8.9.1/8.9.1) with ESMTP id SAB21826; Wed, 23 Jun 1999 18:10:52 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 23 Jun 1999 18:11:43 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id SAA05748 for ; Wed, 23 Jun 1999 18:11:31 -0500 (CDT) Original-Received: from cayuga.cs.rochester.edu (cayuga.cs.rochester.edu [192.5.53.209]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id TAA19661 for ; Wed, 23 Jun 1999 19:10:32 -0400 (EDT) Original-Received: from heart.cs.rochester.edu (heart.cs.rochester.edu [192.5.53.109]) by cayuga.cs.rochester.edu (8.9.3/Q) with ESMTP id TAA00951 for ; Wed, 23 Jun 1999 19:10:18 -0400 (EDT) Original-Received: (from zsh@localhost) by heart.cs.rochester.edu (8.9.3/8.9.3) id TAA05130; Wed, 23 Jun 1999 19:16:10 -0400 Original-To: gnus X-Attribution: ZSH X-Face: 'IF:e51ib'Qbl^(}l^&4-J`'P!@[4~O|&k#:@Gld#b/]oMq&`&FVY._3+b`mzp~Jeve~/#/ ERD!OTe<86UhyN=l`mrPY)M7_}`Ktt\K+58Z!hu7>qU,i.N7TotU[FYE(f1;}`g2xj!u*l`^&=Q!g{ *q|ddto|nkt"$r,K$[)"|6,elPH= GJ6Q Original-Lines: 122 User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) XEmacs/20.4 (Emerald) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:23502 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:23502 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 | | * nndraft.el (nndraft-request-article): Would clobber Japanese. | | 1999-02-04 00:00:35 Lars Magne Ingebrigtsen | | * 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