From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: setenv -> locale-coding-system cannot handle ASCII?! Date: Tue, 4 Mar 2003 13:33:03 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200303040433.NAA07773@etlken.m17n.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> <20030227000638.GA5470@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1046752426 12513 80.91.224.249 (4 Mar 2003 04:33:46 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 4 Mar 2003 04:33:46 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.edu Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Mar 04 05:33:43 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18q47b-0003Fg-00 for ; Tue, 04 Mar 2003 05:33:43 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18q4Qm-0004Fe-00 for ; Tue, 04 Mar 2003 05:53:32 +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 18q47T-0007NN-02 for emacs-devel@quimby.gnus.org; Mon, 03 Mar 2003 23:33:35 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18q47A-0007Mr-00 for emacs-devel@gnu.org; Mon, 03 Mar 2003 23:33:16 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18q479-0007MR-00 for emacs-devel@gnu.org; Mon, 03 Mar 2003 23:33:15 -0500 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18q476-0007Is-00; Mon, 03 Mar 2003 23:33:12 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])h244X4k13702; Tue, 4 Mar 2003 13:33:04 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) h244X4124277; Tue, 4 Mar 2003 13:33:04 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id NAA07773; Tue, 4 Mar 2003 13:33:03 +0900 (JST) Original-To: miles@gnu.org In-reply-to: (message from Miles Bader on 04 Mar 2003 11:48:57 +0900) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) Original-cc: rms@gnu.org Original-cc: sds@gnu.org Original-cc: emacs-devel@gnu.org Original-cc: d.love@dl.ac.uk 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:12089 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12089 In article , Miles Bader writes: > Richard Stallman writes: >> 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). >> >> This is more or less what a unibyte buffer is now, except that there >> is only one possibility for which character sets can be stored in it: >> it holds the character codes from 0 to 0377. > Yeah, but I'm saying that emacs should be able to use this efficient > representation for other character sets as well -- I think it's far more > common to have buffers storing non-raw 8-bit characters than raw > characters, so why is the uncommon case optimized? As for memory, such optimization may be worth considering except for CJK users, but as for speed, not that much. And in emacs-unicode, it gets worse. And, memory is not a big problem nowadays. On the other hand, for the operations on raw bytes, the efficiency of using unibyte buffer/string is really great. [...] > but I also think the current design is somewhat broken, and > makes it too easy for programmers to do the wrong thing. I agree, and, I think the main reason is the automatic adjustment of unibyte<->multibyte. It may be a nifty feature for users, but a very difficult feature for programmers (including emacs maintainers). --- Ken'ichi HANDA handa@m17n.org