[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why are byte ports "ports" as such?
Thomas Bushnell BSG wrote:
Per Bothner <email@example.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:
> 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
> 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
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