emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: can't set both mode-line color and default frame font?


From: Drew Adams
Subject: RE: can't set both mode-line color and default frame font?
Date: Tue, 18 Sep 2007 15:22:34 -0700

> > OK, but that argues that .emacs or `custom-file' is generally a better
> > place to customize than X resources, because it is more
> > flexible/powerful. I'm not sure that argument speaks to the question
> > of precedence when multiple customization sources are employed. It is
> > not uncommon to have a less flexible decision mechanism assume higher
> > precedence/priority.
>
> Emacs Lisp can also choose not to customize something at all.  So if it
> does choose to do so, that has greater weight than the opinion of
> something which only ever has one.

Only if you say it does ;-). That's just repeating the assertion that
`custom-file' (Emacs Lisp) should take precedence over X resource. The
question is "why should it?".

And what do you mean by "choose not to customize"? If a `custom-file' does
not customize some face, and there is an X-resource setting for it, are you
saying that the lack of customization in `custom-file' is "choosing not to
customize", so the X-resource setting should be overridden (ignored)?

In that case, we might as well throw away X resources for Emacs: they are
overridden if the same thing is customized in `custom-file', and they are
overridden (to restore the default) if they are not customized in
`custom-file'.

Maybe I've misunderstood you. I'm not trying to be cute, so correct me if
you meant something different by "choose not to customize".

> We could of course use that power/flexibility to define ways of specifying
> customizations that did and others that did not override X resources (or
> whatever other source), or simply provide a way to (perhaps in the middle
> of some Lisp customizations) reapply the X resources as desired.  These
> would be more complicated than a fixed precedence, but they might be
> simpler than trying to make one mechanism dodge out of the way of the
> other.

Please elaborate. I don't follow.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]