"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
Hrvoje> We aren't developing crappy commercial software here,
Hrvoje> after all. :-)
Right. That's why we should do UCS-4 exactly right, and avoid
getting into "my buffers are bigger" can-you-piss-over-this-line
contests.
No, we should get the buffers right and avoid UCS-x pissing contests.
Your argument doesn't hold water here and I don't like Mule screwing
the rest of us.
BTW: I don't care if Zed has .75GB buffers, or you do, or
somebody
is simply trying to determine the period of (psychoanalyze-pinhead);
I think they're important. Just not as important to me, and I
believe to Mule-dependent people in general, as UCS-4.
I think this conversation is starting to revert me to my original
train of thought, that Mule is not the be-all end-all of everything.
There are other people using XEmacs, and Mule advocates will have to
realize that one of these days.
Yes. UCS-4 is going to be the standard unified character type in
the near future. It can handle all foreseeable needs for plain
text.
Now your argument resembles to those of Markus Kuhn. The important
question is whether UCS-4 is acceptable for our internal
representation. To me it seems that it's not, regardless of whether
it's the "standard unified character type" (ed is the standard editor,
anyway).
>> o XEmacs will never again (well, for a future longer
than the
>> history of electronic computers) need to change the abstract
>> format for a Lisp character.
Hrvoje> This is true without UCS-4 too. It's only the
Hrvoje> implementation that changes.
Unfortunately, probably not true. Current Mule representation has
probably reached the end of the line; we're running out of code
space.
But who cares about that? You're not supposed to be relying on the
value char-int returns, right? Right. The whole idea behind a
character type is that things can be changed without breaking
everything in sight.