Re: Patch: Promoting characters to 31 bits (for discussion)

Hrvoje> No, we should get the buffers right and avoid UCS-x Hrvoje> pissing contests. Your argument doesn't hold water here Hrvoje> and I don't like Mule screwing the rest of us. You're exactly right, and of course I'm exactly right too when I say the exact converse. (Except that both arguments do hold helium, as well as water.) Unfortunately, we're incompatible. So we have to choose. Hrvoje> I think this conversation is starting to revert me to my Hrvoje> original train of thought, that Mule is not the be-all Hrvoje> end-all of everything. There are other people using Hrvoje> XEmacs, and Mule advocates will have to realize that one Hrvoje> of these days. I do. I don't deny the need to choose. We each have the right to advocate that the main line support what we think is important. I will happily fork and maintain a private version of XEmacs, if it goes against me. If there seem to be people interested, I will revisit the issue occasionally. If not, I will bring it up again when changes in XEmacs make it preferable for me to consider a full fork rather than maintain a private version. Hrvoje> Now your argument resembles to those of Markus Kuhn. The Hrvoje> important question is whether UCS-4 is acceptable for our Hrvoje> internal representation. To me it seems that it's not, Because you want that bit. If we weren't competing over the bit, it would be the obvious thing to do (it's been the obvious thing to do for a while; Ben knew that way back when). I'm sure you'd have no objection then, as long is it didn't break any code, and it doesn't need to. In fact, it would make code less likely to break. Hrvoje> regardless of whether it's the "standard unified character Hrvoje> type" (ed is the standard editor, anyway). So? I bet it would be rather easy to turn ed into a UCS-4 editor. Hrvoje> But who cares about that? You're not supposed to be Hrvoje> relying on the value char-int returns, right? Right. The Well, yes, but in practice people do rely on that value; often that value being more reliable than a true character is the reason they use it. I would be happy to break char-int and int-char beyond repair, personally, and spend the effort to make characters reliable. Hrvoje> whole idea behind a character type is that things can be Hrvoje> changed without breaking everything in sight. People who care about efficiency and transparency (ie, extensibility and maintainability) care about internal representation. I'm sure you could cobble up a big-buffer package out of Lisp code, but you would rightly consider that unacceptably fragile and complicated. It's not quite so bad with UCS-4, I admit; we could get half of that space with a not too horrible hack. But it would be a hack, it would hurt transparency, and I can imagine circumstances where we would want to revisit that decision. I see no reason why a full implementation of UCS-4 characters would change again in the life of XEmacs. On the other hand, as you point out, until a standard int is > 32 bits, you are going to need a horrible hack to get beyond 2GB buffers, and for practical purposes, 1GB. And I just don't think that buffer sizes are going to reach a natural constant upper limit at 99.44GB, and then politely give up. You (or someone) are going to implement that hack, and not too far off in the future, I bet. So it really comes down to whether your "rest of us" is bigger than mine. I'm not going to prejudge others' feelings about it. That's my last word in this thread on what we "should" do; we (both of us) are just going in circles. When I have something usable to show, I'll be back, of course. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."