Re: Custom vs. specifier terminology in lisp/faces.el

Thanks much for the reply, I have a much better idea of what I can hack on, and what would just be sand ni the gears. Per> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: Per> The face specifications interface (see the documentation to Per> `defface') don't really have anything directly to do with Per> XEmacs specifier interface. Indirectly, it should solve a Per> subset of the problem XEmacs specifiers are supposed to Per> solve. Unfortunately, that subset excludes Mule. One problem is that Mule inherently involves multiple font families; there is simply no overlap across existing fonts for Japanese, Chinese, and ISO-8859-1, for example. "Unicode" is not an answer, "Unicode" is a question. That is, semantically there are many arguments favoring unification of the Han characters in Unicode, but visually it is not possible to come up with fonts acceptable to both of the two flavors of Chinese, let alone the Japanese and Koreans as well. Saying "use Unicode fonts" is equivalent to giving up on "World Domination Now." In any case there are as yet few Unicode fonts, only one incomplete (AFAIK) free on, and as far as I know, no families that include bold and italic (which are completely differently implemented in Japanese in any case). It is unlikely that that kind of issue (typographical faces) is going to get sorted out without a fair amount of experimentation and displays of nationalistic chest-beating, based on the history of Han unification. Per> Historically, XEmacs at some point generalized `frame' to Per> `locale'. OK. Per> Is that what a tag set is? I read the chapter about Per> specifiers in the XEmacs Lisp manual, and it was completely Per> incomprehensible to me. Yes, that's what the built-in tags are for, and I agree that "incomprehensible" is a good approximation to "excessively abstract." Per> I wrote the face specification interface to have something Per> simple I could understand that would work the same on both Per> Emacs and XEmacs, and hoped someone someday would write a Per> function to translate the simple face specifications into Per> XEmacs specifiers. Much the same idea as easymenu is based Per> on. I believe Hrvoje Niksic tried, but found that the XEmacs Per> specifiers missed some (tags?) necessary. OK, I'll look at this. Missing tags shouldn't be a problem, Custom can define its own. Possibly there's something missing in the semantics of specifiers, or maybe Hrvoje just didn't like the apparent bloat. Per> Not incompatibly, since it is a public function (indirectly) Per> imported from Emacs. I see no reason custom has to use it, Per> as long as the `defface' and `custom-set-faces' interfaces Per> doesn't change. Per> I think you should concentrate on implementing the interface Per> of those two functions, not `face-spec-set'. OK, I guess I'll just ignore the current implementation. When I have something, I'll come back and show it, and you can educate me as to what I've broken and I'll redo it. :-) At your convenience, of course. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Telfax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."