From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: setenv -> locale-coding-system cannot handle ASCII?! Date: Wed, 26 Feb 2003 19:06:38 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20030227000638.GA5470@gnu.org> 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> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1046304617 26988 80.91.224.249 (27 Feb 2003 00:10:17 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 27 Feb 2003 00:10:17 +0000 (UTC) Cc: Kenichi Handa Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18oBck-00070D-00 for ; Thu, 27 Feb 2003 01:10:06 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18oBtP-0005eA-00 for ; Thu, 27 Feb 2003 01:27:19 +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 18oBbN-0006U9-00 for emacs-devel@quimby.gnus.org; Wed, 26 Feb 2003 19:08:41 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18oBal-0006R5-00 for emacs-devel@gnu.org; Wed, 26 Feb 2003 19:08:03 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18oBaV-0006D1-00 for emacs-devel@gnu.org; Wed, 26 Feb 2003 19:07:49 -0500 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18oBZU-0005VT-00 for emacs-devel@gnu.org; Wed, 26 Feb 2003 19:06:44 -0500 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.10) id 18oBZO-0001Vh-00; Wed, 26 Feb 2003 19:06:38 -0500 Original-To: Richard Stallman Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Blat: Foop Original-cc: d.love@dl.ac.uk Original-cc: sds@gnu.org Original-cc: emacs-devel@gnu.org Original-cc: monnier+gnu/emacs@rum.cs.yale.edu 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:11996 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11996 On Wed, Feb 26, 2003 at 06:26:07PM -0500, Richard Stallman wrote: > 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. > > 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! The whole problem in my mind (I'm no expert) is the conflation of these two uses for `unibyte.' It seems to me that `efficiency' should _never_ be a reason to use a unibyte buffer, because the emacs primitives should take care of it automatically -- that is, a buffer/string's should have an associated `unibyte encoding' attribute, which would allow it to be encoded using the straightforward and efficient `unibyte representation' but appear to lisp/whoweve as being a multibyte buffer/string (all of who's characters happen to have the same charset). Obviously inserting a character that didn't match that attribute would be painful (causing the buffer to be completely converted to a real multibyte repsentation), but well, don't do that... :-) -miles -- Fast, small, soon; pick any 2.