Re: proposed Eistring interface

Ben> urk! all of you guys are thinking too literally. the only Ben> intent of this proposal was to allow the *internal* use of Ben> 2^31 char codes, for whatever purpose we feel like, Ben> e.g. dynamic composition. this is *internal only*. perhaps Ben> i really should have rot13'd all the values; then it'd be Ben> clearer :) It's _not_ just internal; if it were, there'd be no point in talking about "Unicode" or "UTF-16 surrogates" at all. The question is to what extent do we want our internal encoding to be compatible with certain external encodings, and why? I say "quite compatible", and because 1. If we are compatible with Unicode, we can use straightforward translations of their published algorithms for stuff like BIDI and maybe compose character and ligature rendering. The more compatible, the less we need to encruft those algorithms with XEmacs-specific data checks. 2. With a little luck we may be able to use system-provided facilities in some cases. IMO it is highly likely that Microsoft et al will provide highly-optimized patented (eg) versions of some of the algorithms. Much as I hate software patents (etc), I think users should have the advantage of their platform. 3. I think it would be nice to be able to read the contents of buffers and strings with a debugger in a Unicode-capable TTY, without tripping over XEmacs-specific encoding details. But this is obviously no biggee. -- 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 straight lines for? "XEmacs rules."