From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/30724 Path: main.gmane.org!not-for-mail From: Shenghuo ZHU Newsgroups: gmane.emacs.gnus.general Subject: Re: more multibyte bugs Date: 05 May 2000 11:23:59 -0400 Organization: U of Rochester Sender: owner-ding@hpc.uh.edu Message-ID: <2nln1prpf4.fsf@tiger.jia.vnet> References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035167220 10003 80.91.224.250 (21 Oct 2002 02:27:00 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:27:00 +0000 (UTC) Return-Path: Original-Received: from lisa.math.uh.edu (lisa.math.uh.edu [129.7.128.49]) by mailhost.sclp.com (Postfix) with ESMTP id 3A30FD051E for ; Fri, 5 May 2000 11:24:11 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by lisa.math.uh.edu (8.9.1/8.9.1) with ESMTP id KAB25588; Fri, 5 May 2000 10:24:09 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 05 May 2000 10:23:15 -0500 (CDT) Original-Received: from mailhost.sclp.com (postfix@[204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id KAA16693 for ; Fri, 5 May 2000 10:23:03 -0500 (CDT) Original-Received: from shenghuo.dhs.org (d185d1eec.rochester.rr.com [24.93.30.236]) by mailhost.sclp.com (Postfix) with ESMTP id 950F6D051E for ; Fri, 5 May 2000 11:22:00 -0400 (EDT) Original-Received: (from zsh@localhost) by shenghuo.dhs.org (8.10.0/8.10.0) id e45FNxA11498; Fri, 5 May 2000 11:23:59 -0400 Original-To: ding@gnus.org 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 In-Reply-To: Vladimir Volovich's message of "05 May 2000 12:57:17 +0400" Original-Lines: 56 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.6 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:30724 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:30724 >>>>> "VV" == Vladimir Volovich writes: VV> Hi Shenghuo, VV> with current cvs i'm able to send messages in koi8-r with VV> CTE=8bit. Thanks for good work! BTW, i wonder why sending via VV> smtp worked fine in prev. versions, and was broken in some recent VV> one (and was fixed without touching smtp sending code?). You are using koi8-r as your default coding system. In the previous versions, the 8-bit data are copied, decoded and encoded, as if they are koi8-r characters. For 8bit koi8-r message, there is no problem. Even for iso-8859-? and some other coding systems, koi8-r decoding, then encoding, do not hurt the 8-bit data. But it is not Right Thing (TM). Now, every buffer for prepared messages are unibyte, i.e., it is safer for CTE=8bit. In the recent fix, I set the default value of enable-multibyte-characters in mm-with-unibyte-current-buffer so that all new buffers generated within the scope will be unibyte, including those generated in smtpmail.el. VV> With the current cvs version, there is one more bug that i just VV> noticed: open any message with 8-bit CTE, press TWICE C-u g, and then VV> get it again. I.e. press VV> g VV> C-u g VV> C-u g VV> g VV> Then 8-bit text will be broken. Those multibyte problems are VV> really bad and tricky. :-) The article buffer is unibyte, right? I just fixed it. If it doesn't work, tell me. VV> BTW, as you agreed to use unibyte encoding for mbox, but you think VV> that it could be a disuster, i suggest to create a cvs "multibyte VV> cleanup branch" in which you could try to Do The Right Thing (TM); VV> i'll be happy to debug this branch and report problems. When VV> everything works fine, we could merge it into the main branch. The problem is caused not only by open-file, but by the operations of insert, buffer-string and others. So, we can not simply create a buffer as unibyte, because MULE characters and 8bit raw characters may exist in a buffer at the same time. Currently, I fixed some bug by dynamically switching between unibyte and multibyte (mm-with-unibyte-current-buffer). I hope it works fine. Yesterday, I created an mbox and copied an 8bit utf-8 message into it after I fixed a unibyte bug in mm-insert-part. It works fine. Could you test it again? If it not fixes the problem, please send the message to me as base64 attachment. -- Shenghuo