Re: Customize bug?
Per Abrahamsen <abraham(a)dina.kvl.dk> writes:
The unbundled code doen't *touch* specifiers, as they are
unnecessary
for what it tries to do. It uses the pre-specifier API's together
with `make-frame-hook', which is sufficient.
The pre-specifier API internally uses specifiers, only in what one
could call a more primitive way. And the bundled code does it the
same way.
I suspect most of the current problems is caused by a port of the
code to specifiers, that only got halfway finished.
No, the port of the code to specifiers never even got started. I used
to have an alpha working version, but I gave up because
`background-mode' is unimplementable in the current framework.
I agree that most (but not all!) of the current problems were caused
by my never-quite-finished merge with XEmacs' faces.el. The unbundled
code had, however, other problems; for instance, I recall that you
couldn't dump XEmacs with code that used `defface'.
> In FSF Emacs this is trivial since customize exactly matches
the
> FSF font model. Adapting customize to more powerful font models
> (whether for XEmacs or for FSF 20.5+) without overly complicating
> the interface will be a challenge.
There is no XEmacs font model, which is the only hard thing about
it.
True. font.el provides some of the needed functionality, but it's way
too naive to be taken seriously (no offense Bill!) Not to mention
that the redisplay doesn't support merging of font properties.
> I think I know how to fix the MULE problems. (By doing a
partial
> port to specifiers. This fixes the
> throw-away-what-I-don't-understand attitude the Customize takes on
> XEmacs).
On both emacsen. But you can overwrite the customize setting with X
ressources, which only leaves explicit Lisp settings.
It depends. I think the *default* customize settings (such as in
`defface' forms) should be overridden with X resources. On the other
hand, hand-changed customize settings (such as with `M-x customize-face')
should override X resources.