Re: Release candidate for XEmacs 21.4.4 / my vacation

Alexey> You can't "conditionalize" it. It depends upon what Alexey> encoding user's fonts have, and you can't guess it. Sure you can. You start by guessing that the user wants KOI8-R fonts. That's pretty likely to be valid, wouldn't you say? Then `(list-fonts "-*-koi8-r")' will tell you whether there are any. If there are, use them. You can make this nicer by mapping that over a list of common "nice" fonts, and adding customization so the user can define the list of nice fonts. (This _should_ already Just Work but the Custom Gods never saw fit to implement it.) Hmm. Does the current face mechanism handle this correctly (the situation where the charset registry and the XLFD registry are different)? Gotta check that. [You can do it if you want but this message is going into my TODO queue, and I'll get to it eventually....] Alexey> Actually the general documentation is there (see my Alexey> patches regarding Mule and fonts, which are already in). In my "these patches have no ChangeLog" queue, you mean? They're in 21.4 now.... Alexey> What is needed is the specific reference of all existing Alexey> ccl-programs that are defined within XEmacs and used for Alexey> fonts re-encoding. I hope we'll write that one soon. lisp/mule/chinese.el:(define-ccl-program ccl-encode-big5-font lisp/mule/cyrillic.el:(define-ccl-program ccl-encode-koi8-r-font lisp/mule/cyrillic.el:;; (define-ccl-program ccl-encode-alternativnyj-font lisp/mule/ethiopic.el:(define-ccl-program ccl-encode-ethio-font lisp/mule/vietnamese.el:(define-ccl-program ccl-encode-viscii-font lisp/mule/vietnamese.el:(define-ccl-program ccl-encode-vscii-font Alexey> Currently I have to include the "patch cyrillic.el if your Alexey> fonts are in koi8-r" clause into F.A.Q. Alexey> I want to simply say "Take 21.4.4 and put two lines to Alexey> emacs.el". Please :) OK. The FAQs will be automatically redirected.... I really need to get this stuff out of core; technically I'm supposed to clear it before it goes in, but it's just an obstacle to progress in some sense. The issue is that it should "just work" if it's core; that's why I'm being stubborn. Packages are up to the package maintainer; if we could find some way to put this in a package and still reliably dump it for people who want it, that would be much nicer. You _can_ always package the Lisp parts and override core by loading the package, if you want to speed up approval. You just get the package in, and Steve Y is easier about that than I am about core changes. Then you be maintainer, and you're boss. But you run into the "it doesn't Just Work" until the package is loaded, more FAQs etc, problem. [Just a suggestion; on balance I think it's better to put the effort into the core for now. Again, something for _my_ TODO queue but I certainly won't object if you do something about it first. :-)] -- 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."