This page is part of the web mail archives of SRFI 91 from before July 7th, 2015. The new archives for SRFI 91 contain all messages, not just those from before July 7th, 2015.
Thomas Bushnell BSG wrote:
Per Bothner <firstname.lastname@example.org> 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 email@example.com http://per.bothner.com/