Re: Unibyte characters, strings, and buffers

[David Kastrup]

"Stephen J. Turnbull" <address@hidden> writes:

> David Kastrup writes:
>  > "Stephen J. Turnbull" <address@hidden> writes:
>
>  > > It just requires a slightly more complex design, which would be
>  > > appropriate for Emacsen (as compared to Python).
>  > 
>  > If the "slightly more complexity" hits in unexpected places, it's going
>  > to end up a liability.  Having more than one charset to work with if
>  > characters themselves don't contain a charset specification is affecting
>  > a load of stuff that can then conceivably work in more than one
>  > way.
>
> I'm a little smarter than that.

Building on smartness is relying on a limited resource.  It's not always
easy to find wingmen (pun intended but unworkable).

> The design I have in mind would be transparent.

I don't think it gets much more transparent than "unibyte flag only
marks the valid Unicode-in-Emacs character range".  I'm for the range
0..255, Andreas for something like 0..127 U 4194176..4194303 which
I find cumbersome for little return.

> Maybe it wouldn't work; maybe it would be inefficient.  But one thing
> it wouldn't do is present a charset other than Unicode to Lisp.

Neither does the above.  Abolishing unibyte just means that
buffers/strings have only one possible character range.  That does not
really give any "transparency" per se from the Lisp level.  The
interesting level is the C level.  You need a byte stream representation
in C at some point anyway, and not being able to call this
representation either "string" or "buffer" may be neat in some manners
but will end up cumbersome in others.

-- 
David Kastrup