Re: unicode internal issues

Ben> char-charset, char-octet and split-char will remain in a Ben> unicode world Why? Isn't this the Ebola thing all over again? I think we should design the API under the assumption that we're going to get rid of those functions. Instead, there should be translation functions (ie, codecs) that take an explicit coded character set argument for those cases where it's needed (eg, X11 font registries). Ben> internally, some concept like "leading byte" will remain but Ben> will simply be an arbitrary charset index. Again, I don't see what this is for in principle. We might want to cache something like that for efficiency in redisplay (and that only on core X11 displays, even Xft doesn't need it), but that should be encapsulated in the implementation. Of course in a second stage we'll probably want Mule emulation for backward GNU compatibility (eg for MUAs), but I think we should see how far we can go without "old Mule" baggage. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.