From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Emacs-diffs Digest, Vol 2, Issue 28 Date: Mon, 03 Mar 2003 13:59:42 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200301200152.KAA16258@etlken.m17n.org> <200301280032.JAA15601@etlken.m17n.org> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1046718440 12017 80.91.224.249 (3 Mar 2003 19:07:20 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 3 Mar 2003 19:07:20 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18pvHT-00037h-00 for ; Mon, 03 Mar 2003 20:07:19 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18pvaS-0007Je-00 for ; Mon, 03 Mar 2003 20:26:56 +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 18pvHV-0002ml-0C for emacs-devel@quimby.gnus.org; Mon, 03 Mar 2003 14:07:21 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18pvG0-0002B3-00 for emacs-devel@gnu.org; Mon, 03 Mar 2003 14:05:48 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18pvEd-0001sB-00 for emacs-devel@gnu.org; Mon, 03 Mar 2003 14:04:24 -0500 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18pvAF-0000Wx-00 for emacs-devel@gnu.org; Mon, 03 Mar 2003 13:59:51 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.10) id 18pvA6-0004rD-00; Mon, 03 Mar 2003 13:59:42 -0500 Original-To: Kenichi Handa In-reply-to: <200301280032.JAA15601@etlken.m17n.org> (message from Kenichi Handa on Tue, 28 Jan 2003 09:32:54 +0900 (JST)) 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:12079 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12079 It is fairly clear for the case that a process has a fileter and coding system is no-conversion or raw-text. But what to do with the other coding systems (e.g. Latin-1, iso-2022-jp). If a process is unibyte, what kind of string, the filter should get? Should we suppress a text decoding like the case of inserting a file into a unibyte buffer? I don't see any other meaningful thing to do in that case. Decoding produces, in general, data that cannot go in a unibyte string. And if the process has no filter but has a buffer, what to do for a unibyte process that has a multibyte buffer, or for a multibyte process that has a unibyte buffer? These are unreasonable cases, so there is no need to strain to hard to make them do useful things. For the unibyte process with a multibyte buffer, just turn off decoding, and let the data get converted to multibyte when inserted in the buffer. For the multibyte process with unibyte buffer, it can convert the multibyte decoded text to unibyte. If people feel that isn't useful, they shouldn't use it. And what to do with process-send-string/region. If the process is multibyte, encode the text (after converting it first to multibyte if necessary). If the process is unibyte, just convert the text to unibyte. A string given to a process filter must be the same as the result of that code, which means that default-enable-multibyte-characters decides the multibyteness, and if it is nil, character conversion except for end-of-line conversion is suppressed. default-enable-multibyte-characters should not directly control the multibyteness of the string. The process's multibyte flag should control that. But it is a good idea to let default-enable-multibyte-characters play a role in initializing the process's multibyte flag. Or, was the intention of set-process-multibyte actually set-process-filter-multibyte? You could think of it that way, because the case where set-process-multibyte is useful is when the process has a filter.