Re: setenv -> locale-coding-system cannot handle ASCII?!

[Kenichi Handa <handa@m17n.org>]

In article <buod6l73kyu.fsf@mcspd15.ucom.lsi.nec.co.jp>, Miles Bader <miles@lsi.nec.co.jp> writes:
> Richard Stallman <rms@gnu.org> 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