From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: setenv -> locale-coding-system cannot handle ASCII?! Date: Wed, 26 Feb 2003 03:12:38 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200302260812.h1Q8CcO10018@rum.cs.yale.edu> References: <200302250634.PAA27478@etlken.m17n.org> <200302260058.JAA28973@etlken.m17n.org> <200302260211.h1Q2BJl08373@rum.cs.yale.edu> <200302260234.LAA29082@etlken.m17n.org> <200302260252.h1Q2qIK08490@rum.cs.yale.edu> <200302260532.OAA29294@etlken.m17n.org> <200302260550.h1Q5oSc08967@rum.cs.yale.edu> <200302260749.QAA29494@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 1046247305 29392 80.91.224.249 (26 Feb 2003 08:15:05 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 26 Feb 2003 08:15:05 +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 18nwiS-0007dW-00 for ; Wed, 26 Feb 2003 09:15:00 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18nwyn-0004T3-00 for ; Wed, 26 Feb 2003 09:31:53 +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 18nwhy-0000hk-09 for emacs-devel@quimby.gnus.org; Wed, 26 Feb 2003 03:14:31 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18nwgj-00008m-00 for emacs-devel@gnu.org; Wed, 26 Feb 2003 03:13:13 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18nwgI-0007rz-00 for emacs-devel@gnu.org; Wed, 26 Feb 2003 03:12:47 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18nwgD-0007k6-00; Wed, 26 Feb 2003 03:12:41 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id h1Q8CcO10018; Wed, 26 Feb 2003 03:12:38 -0500 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Kenichi Handa 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:11966 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11966 > In article <200302260550.h1Q5oSc08967@rum.cs.yale.edu>, "Stefan Monnier" writes: > >> Why is it not needed? Strings and buffers are not that > >> different, both are containers of characters. > > > They are used differently. Operations on strings generally apply to the > > whole string: you can only encode/decode a whole string at a time. > > That's because of the limitation of the current > implementation, not because of the nature of strings. I think it's the nature of strings and of the functions we provide on them. If the user wants to do anything else, she uses a buffer instead where modifications are easy to make and where you have things like markers, point, ... > There's no reason for keeping that limitation. Actually, as > we have changed the type Lisp_String in 21.1, it's not > difficult to make strings change length. Actually, strings are virtually never changed so it would be silly to do that. When a string needs to be changed, 99% of the functions simply create a new string. I know of only two cases where a string is mutated: set-text-properties and aset. The copy of Emacs that I use every day has aset disabled on strings and works very well despite that (it did require a few minor changes in a handful of packages). Emacs strings are 99% immutable. In practice it's also the case for Scheme strings, BTW, and there's always been hot debates about whether or not to change the Scheme language to specify that strings are not mutable. > ------------------------------------------------------------ > What a character in a unibyte buffer represents depends on a > context. It may be a character represented by a single > byte, or a raw byte not yet decoded, or a byte constituing a > multibyte form of the different character. > > On the other hand, a character in a unibyte string always > represents a raw byte. Emacs coerces it into a character > represented by that single byte when a unibyte string is > concatenated with a multibyte string, or it is inserted in a > multibyte buffer. > ------------------------------------------------------------ > > But, I'm not sure such a change is really necessary. Are > you sure that the change doesn't break the current usage of > unibyte strings? I'm pretty sure it'll break current usage in a few places. > > PS: I wish there was a way to swap two buffers's content so that > > tar-mode could swap the (potentially very large) data to > > a helper buffer (without needing to copy this large data) > > and then use multibyte for the display and unibyte for > > the helper buffer. > > I don't understand what you mean, especially the usage of > the helper buffer. > > I think tar-mode should use multiple buffers, one unibyte > buffer for tar-file itself, one multibyte buffer for table > of contents, and the other multibyte buffers (created on > demand) for viewing/editing files contained in the tar-file. > Then, tar mode works almost the same way as dired. We can > see multibyte files in the different buffers. We can use > the same method in arc-mode and also in RMAIL. > > Is that different from what you mean? No, that's exactly what I meant, but the problem is the following: When tar-mode is called, the current buffer already contains the 24MB binary content of the file and it is also the buffer that should in the end contain the table of contents, so you need to somehow move those 24MB from this buffer to a new one (the "helper" one). Stefan