Re: [21.0b63] make-face-bold is broken under CYGWIN+X...
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
non-ISO-8859-1 font information (using reset-face); now (if I
understand what Jan has done correctly) it saves that information,
but can't change it. Someday (soon, I hope) somebody is going to fix
this.
No I proposed doing that but that is not the patch that went in. What
it does now is trying to reconstruct the face after destroying it wiht
reset-face. Note that currently it does not call the code that sets up
the mule fonts again (It probably should). The upshot is that custom
will probably still hose your Mule faces.
Maybe what it should do in addition to that is use not 'reset-face'
but something similar that leaves all the fonts with the 'mule-font'
tag alone.
What I really don't understand is how the FSF Emacs manages to use
custom without destroying all of the Mule stuff.
I don't know without a careful analysis whether your patch would
interfere with this improvement or not. Many of the functions in
faces.el were once part of the Custom superstructure IIRC.
His changes look correct to me.
One thing I just noticed that bothers me is that you have usurped
the
TAG-SET argument of the specifier functions for just one class of
tags: the device tags. However, there are several others, including
visual and user-defined, and I think that you should allow for the
possibility that somebody (in particular, Mule programmers) will want
to pass arbitrary tag sets.
Huh? Current ALL tag-sets are device tags. Some of them may be user
defined but they are related to the device. In fact if it were
possible to have efficient tags that worked at every locale it would
be a lot easier to implement Custom atop of specifiers.
Yes. If you look at the comments in the LISP sources and
Changelogs,
you'll see that nobody is yet sure what belongs to Custom and what
belongs to XEmacs. Nobody is willing to take ownership of it; I don't
have the time to get enough understanding of Custom, the people who
know Custom don't really understand Mule or in some cases specifiers,
and they don't have time to study it either.
This is really the root of the problem. The specifier side of things
at least has good documentation. Custom already a lot less (especially
things like the exact meaning of the face specs etc) and Mule
basically has/had no documentation.
Jan