(Excuse my late reply to this, I simply forgot about it.) On Thu, Aug 28, 2003 at 03:54:11PM +0700, Ivan Pascal wrote:
..[snip].. > Locale independence. > > In existent files a compose rule consists of two parts. A 'left side' part is > a sequence of keysym and a right part (the result of composing) is a pair of > a mylti_byte string and a keysym. Both members ot that pair are independed. > Each of them can be omited and the compose subsystem doesn't check any > matching between them and doesn't figure out any one of them from other. Ah, so you mean that we can simply omit the string part of the rule, and it will work just fine with only the keysym part? Well, that's great to hear. :^) Thanks to your work on "unicode keysyms", there's really no need for the string part these days, so we could indeed have completely locale independent Compose files. Very nice. :^) > Customization. > > I added to Compose file an 'include' instriction. It allows to compose > Compose file :-) from some files and add small corrections that user prefers. > E.g. if user has custom Compose file it can look like > > include "<system wide file>" > my_own_rules > ... > > Of course, if some rules overlap, Xlib just discards a previous rule and uses > latest one. Oh, so in combination with the above, we can now have locale independent Compose file snippets, that can be included to form the full files. Wonderful. Even with the existing configuration framework (Compose gets defined by the locale) this would immediately solve a couple of problems for me, namely: - No more having to maintain separate files with the exact same definitions for different character sets, ISO-8859-7 and UTF-8 in my case. Just write the snippets and include them as necessary. - No more having rules of limited use because they exist in one locale only. Right now, to use decent polytonic greek compose rules, one has to switch to el_GR.UTF-8. But with your work included, I could split these rules to a separate file, which could easily be included by any locale. And some more, such as: - With includes, it would be very easy to accommodate requests like "in Brazilian locales dead_acute+c should produce ccedilla" with minimal duplication of code. - We could broaden the compose definitions even for 8-bit locales, so that Unicode-aware applications (such as Mozilla) would use them under any locale. If these changes go in, I guess we will probably need a directory /usr/X11R6/lib/X11/locale/include to place such included files. > Also I think some substitutions in the included file name could be usefull. > A made two ones: %H means the value of HOME variable and %L means the name > with full path to a currently used local-depended file (e.g > /usr/X11R6/lib/X11/locale/iso8859-1/Compose). > The first substitution woild allow to add a per-user preference file into > a 'system' Compose file, e.g. > > system-wide file: > common_rules > ... > include "%H/.XCompose" > > If the file doesn't exist Xlib silently ignores such instruction. > > The second substitution would allow user to add currently used files into own > custom Compose file without care where that file is actually placed. No objections here. Just don't forget to add at least another substitution, %%, which produces a literal %, for completeness' sake. > In finally a most doubtfull part: how to specify needed Compose file. > Now I made an environment variable XCOMPOSEFILE which value should be a name > (with a path) of Compose file. But I realize it is unhandly for users. > Any ideas are welcome. Hm, how about simply checking for the presence of ~/.Xcompose and using it instead of the locale dependent file? In that case, this file would have to include the system wide ones instead of the other way round, so perhaps the substitutions you've proposed wouldn't be really needed. > P.S. All changes I'm talking about are already made and tested. I can commit > them in any time. But I'd like to hear suggestions/objections. Indeed, once we've settled all the issues, committing is the right thing to do. :^) Again, great work! -- Vasilis Vasaitis [EMAIL PROTECTED] +306976604701 _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
