Thomas Bushnell BSG wrote:
> Per Bothner <xxxxxx@bothner.com> writes:
>
>>> Except that text is an assemblage of characters, not of code points.
>>> The editor needs functions like "display this character",
>> No, it needs functions like "display this string".
>
> Do you use emacs?

Yes.  What's more I've *implemented* (an) Emacs:
http://per.bothner.com/papers/JEmacs02/jemacs.html

 > Do you ever use C-x =?

No.

> Sorry, but I think of a string as an array of characters.

It's not: the index of a character in a string has no semantic meaning.
A byte-offset would work just as well: It's just a "position".

> Great, then you don't need characters.  But *certainly* this is not an
> argument for taking code points and *calling* them characters.

The argument is that we have nothing better that we can call characters,
and if we use code-points we can use the historical Scheme functions
and names.

 > No, [fonts] are not [indexed by code-point].  They are indexed by
 > character.  Consider an accented character that is represented by
 > several code points.

This can be handled the same way an ffi ligature is handled.  Are you
proposing that #\ffi be a character?

>> Anyway, this is all irrelevant.  Until you specify an actual
>> "character API" and propose a practical implementation strategy,
>> then I think the discussion is pointless.
>
> I see, I think I already had.  Was that missing?  I'm content with the
> scheme character API, with the case-related functions fixed or
> removed.

What does char->integer return?  How does char<? work?  What is your
proposed implementation for a "character" in the Unicode world, given
that it is not a code-point?  How would you store characters in a
string?
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/