From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Mario Lang Newsgroups: gmane.emacs.devel Subject: Re: [HELP] (bug?) Saving a buffer without any conversion? Date: Wed, 15 Jan 2003 17:59:10 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87n0m2uz6p.fsf@lexx.delysid.org> References: <87fzrxszs8.fsf@lexx.delysid.org> <200301150116.KAA09223@etlken.m17n.org> <5xk7h67k1b.fsf@kfs2.cua.dk> <200301151059.TAA09873@etlken.m17n.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1042651799 30192 80.91.224.249 (15 Jan 2003 17:29:59 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 15 Jan 2003 17:29:59 +0000 (UTC) Cc: storm@cua.dk Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18YrMU-0007qq-00 for ; Wed, 15 Jan 2003 18:29:58 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18YrV1-0005Ge-00 for ; Wed, 15 Jan 2003 18:38:48 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18YrMv-0004B4-02 for emacs-devel@quimby.gnus.org; Wed, 15 Jan 2003 12:30:25 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18YrAx-0006TK-00 for emacs-devel@gnu.org; Wed, 15 Jan 2003 12:18:03 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18YqtN-00011o-00 for emacs-devel@gnu.org; Wed, 15 Jan 2003 11:59:55 -0500 Original-Received: from [80.109.223.66] (helo=lexx.delysid.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18Yqt0-0000hQ-00 for emacs-devel@gnu.org; Wed, 15 Jan 2003 11:59:31 -0500 Original-Received: from mlang by lexx.delysid.org with local (Exim 3.36 #1 (Debian)) id 18Yqsg-00037m-00; Wed, 15 Jan 2003 17:59:10 +0100 Original-To: Kenichi Handa In-Reply-To: <200301151059.TAA09873@etlken.m17n.org> (Kenichi Handa's message of "Wed, 15 Jan 2003 19:59:04 +0900 (JST)") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) Original-cc: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:10755 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10755 Kenichi Handa writes: > In article <5xk7h67k1b.fsf@kfs2.cua.dk>, storm@cua.dk (Kim F. Storm) writes: >> He uses a process filter to "insert" the received strings to the >> buffer like this [approximately]: > >> (defun filter (proc string) >> (with-current-buffer (process-buffer proc) >> (insert string))) > > Ah! Now I see what's going on. If the coding system for > proc is no-conversion or raw-text, STRING above is unibyte, > thus, when inserted in a multibyte buffer, it is converted > to the corresponding multibyte string. This conversion > converts all 0xA0..0xFF to Latin-1 (in Latin-1 lang. env.). Thanks for this explaination. As Kim already pointed out, I think this should be documented somewhere more clearly. At least to me it was very mysterious why some kind of conversion happend, even if I specified 'no-conversion in all possible places... >> Here is a small, selfcontained test case. > >> If you eval the following form, wait a few seconds, the result is >> "BUFFER=10 FILE=20" >> meaning that the temp.out buffer is 10 "bytes", but the written >> file is 20 "bytes". > >> Adding the "set-buffer-multibyte" line produces the right result. > > Yes. And, instead of adding that, chaging this: > >> :filter (lambda (proc string) >> (with-current-buffer (get-buffer "temp.out") >> (insert string))) > > to this: > >> :filter (lambda (proc string) >> (with-current-buffer (get-buffer "temp.out") >> (insert (string-as-multibyte string)))) > > also produces the right result. > > Which is the better solution? It depends on how the buffer > is used later. If it is just to save the received bytes in > a file, using a unibyte buffer is better. But, in that > case, first of all, why is the process filter necessary? In that specific case, the filter function is necessary because the protocol used requires sending confirmation-packets whenever we received data... -- Thanks again, Mario