[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: setenv -> locale-coding-system cannot handle ASCII?!
From: |
Kenichi Handa |
Subject: |
Re: setenv -> locale-coding-system cannot handle ASCII?! |
Date: |
Tue, 4 Mar 2003 13:33:03 +0900 (JST) |
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) |
In article <address@hidden>, Miles Bader <address@hidden> writes:
> Richard Stallman <address@hidden> 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
address@hidden