Re: [21.0b63] make-face-bold is broken under CYGWIN+X...
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
I don't think this works right. It postpones the day when
Custom
learns to handle mule fonts, too. :-/
I'm thinking 21.0/21.1 solutions here. Unless you think it is better
to tell Mule users not use customize until it has been tamed.
FSF uses explicit fontSets (instead of specifier magic which allows
multiple fonts to coexist if they have different registries). I bet
that this is implemented in such a way as to be equivalent to not
using `reset-face'.
I just looked at the FSF 20.3 source at ftp.ifi.uio.no and this part
of their face-spec-set
(modify-face face '(nil) '(nil) nil nil nil nil nil frame)
looks almost like an reset-face to me.
Note that from the look of it FSF Emacs simply does not implement the
font name part of custom! (and thus do not have these problems).
Jan> Huh? Current ALL tag-sets are device tags. Some of them
may
Jan> be user defined but they are related to the device. In fact
'mule-font and 'default are not really "user-defined" even if they are
created with `define-specifier-tag'. They aren't device tags.
Currently ALL tag sets are device tags. See below
Jan> if it were possible to have efficient tags that worked
at
Jan> every locale it would be a lot easier to implement Custom
Jan> atop of specifiers.
(What do you mean by "efficient" and "work at every locale"?)
What I mean is the following:
a tag set is a filter. Effectively it is not the complete specifier
that is used when looking for a font-instance for display but it is
just those parts that have the tags associated with the device as
a subset of the tag set (with a special case for nil). Therefore you
can add things like 'default and 'mule-font for other uses but XEmacs
thinks they are device tags.
What I would like is that this mechanism is generalized as follows.
I would like that not only the device locale is associated with a tag
set but also the other locales. Then when matching it is not the
device tags that are used as a filter, but the current locale's.
For instance the customize 'dark and 'light spec-tags depend on the
background of the default font in that window and are therefore window
specific. This would allow complete implementation of custom-specs in
terms of specifiers.
The problem with this is doing it efficiently. Currently tags
are aggressively cached at device level. The computation is really
only done at device creation time and when defining new tags. Both of
these are rare events. Creation of buffers and windows occurs much
more often, therefore you need a much smarter cache.
Suppose I wanted to use a tag set? Paul's code doesn't allow
for
that; his code passes and expects to receive a symbol.
Sorry I missed that. He should allow passing a list (this should be
easy). Just ditch the '(list func-tag) and do it at an higher level.
simple enough to change that. My point is that it is not true that
the tags are mutually exclusive, tag sets are necessary in general,
and I don't know---and neither does anyone else, right?---about this
particular code.
No but Paul has real problems that need to be fixed. His setup might
be rare now but it might not be in the future. This does seem the
right way to fix that. You have settings that are valid only for a
particular type of device so you add a tag set to reflect that. The
current code is just a cop out.
Jan