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: setenv -> locale-coding-system cannot handle ASCII?! Date: Wed, 26 Feb 2003 18:26:07 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200302250634.PAA27478@etlken.m17n.org> <200302260058.JAA28973@etlken.m17n.org> <200302260211.h1Q2BJl08373@rum.cs.yale.edu> <200302260234.LAA29082@etlken.m17n.org> <200302260532.OAA29294@etlken.m17n.org> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1046302187 17412 80.91.224.249 (26 Feb 2003 23:29:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 26 Feb 2003 23:29:47 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.edu Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18oAze-0004WS-00 for ; Thu, 27 Feb 2003 00:29:42 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18oBGH-0005Gm-00 for ; Thu, 27 Feb 2003 00:46:54 +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 18oAzA-0003Da-08 for emacs-devel@quimby.gnus.org; Wed, 26 Feb 2003 18:29:12 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18oAwm-0001SS-00 for emacs-devel@gnu.org; Wed, 26 Feb 2003 18:26:44 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18oAwI-0001FW-00 for emacs-devel@gnu.org; Wed, 26 Feb 2003 18:26:14 -0500 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18oAwB-0001E8-00 for emacs-devel@gnu.org; Wed, 26 Feb 2003 18:26:07 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.10) id 18oAwB-0000ZD-00; Wed, 26 Feb 2003 18:26:07 -0500 Original-To: Kenichi Handa In-reply-to: <200302260532.OAA29294@etlken.m17n.org> (message from Kenichi Handa on Wed, 26 Feb 2003 14:32:16 +0900 (JST)) Original-cc: d.love@dl.ac.uk Original-cc: miles@gnu.org Original-cc: emacs-devel@gnu.org Original-cc: sds@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:11990 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11990 So, in a multibyte sesstion "(format "%s" 1)" yields a multibyte string. :-( If format sees that all the characters are one-byte, it could make this a unibyte string. By the way, I also really really hate this unibyte/mulitbyte problem. Sometimes I think I should have opposed to the introduction of such a concept more strongly. It is possible that nowadays we do not need unibyte buffers and strings any more. Perhaps now the only kind of benefit that a unibyte buffer provides is a speed advantage for Tar mode and similar programs. It would be interesting to find out if tar mode works right with multibyte buffers, and if so, how much of a slowdown that entails when reading a large tar file. But there may be another benefit. Using unibyte buffers would also mean that the user will never be asked what encoding to use. And some users may really dislike being asked! We could imagine replacing the current unibyte mode of operation with one in which visiting files always uses no-conversion but makes multibyte buffers, and then make sure that works just like using unibyte buffers does now. If we get that to work well, then we could use that instead of unibyte mode. Then we could reserve unibyte buffers for things like tar-mode, or use eliminate them entirely if tar-mode runs fast enough with multibyte buffers.