Ar an t-ochtú lá déag de mí Eanair, scríobh Stephen J. Turnbull:
Aidan Kehoe writes:
> lisp/ChangeLog addition:
> 2007-01-02 Aidan Kehoe <kehoea(a)parhasard.net>
> * cus-face.el (custom-set-face-update-spec):
> Fix some formatting.
> * faces.el (reset-face):
> reset-face resets other faces to behave like the default face--it
> shouldn't do anything if it's handed the default face.
I don't understand why you changed the code rather than the docstring.
The code that called it relied on it not reverting the default face.
Ie, it makes sense to reset the default face, which results in it
behaving according to its fallbacks. `reset-face' is marked as a
dangerous, irreversible function; isn't that enough?
> * font-menu.el:
> * font-menu.el (font-menu-set-font):
> If the font was initialised from X resources (the tag-set
> contains 'x-resource) pretend to Custom that it has
> responsibility for those settings.
I don't understand the logic for this. If people want a font to be
controlled by Custom, let them set it via Custom, no? Is this needed
to make the font-menu work?
The font-menu uses Custom to change the face family and size, which is well
and good, duplicating the frobbing Custom does would be a waste. If,
however, a face specifier doesn’t have 'custom in its specifier tag list, as
will be the case if it was initialised from X resources or from the
corresponding fallback, Custom won’t modify a faces.
I guess you can recover the resource settings by reinitializing the
but wouldn't it be preferable to keep the resource-based instantiators
and implement reset-to-default by clearing instantiators with the Custom
That’s the current situation, and it has the disadvantage that the font menu
Brief testing indicates that the font menu is still very broken under
Xft. That's expected, right? I haven't tried a non-Xft build yet.
That’s expected, yes--haven’t got to it yet.
When I was in the scouts, the leader told me to pitch a tent. I couldn't
find any pitch, so I used creosote.
XEmacs-Patches mailing list