[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]