Re: Why are byte ports "ports" as such? Per Bothner 24 May 2006 04:27 UTC

Thomas Bushnell BSG wrote:
> Per Bothner <> 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:

 > Do you ever use C-x =?


> 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
	--Per Bothner