[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unibyte characters, strings, and buffers

From: David Kastrup
Subject: Re: Unibyte characters, strings, and buffers
Date: Sun, 30 Mar 2014 11:01:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

"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

reply via email to

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