[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: problems with face-spec-reset-face and set-face-attribute
From: |
Drew Adams |
Subject: |
RE: problems with face-spec-reset-face and set-face-attribute |
Date: |
Sat, 22 Oct 2005 22:49:12 -0700 |
> My comment about a possible bug specific to :inherit was because
> evaluating the same expression, namely
>
> (set-face-attribute 'completions-first-difference nil
ATTR 'unspecified)
>
> when ATTR is different from :inherit, e.g. :background or
:slant, does
> work as Drew expected, and as the doc strings say it should.
In my tests this doesn't work for other attributes too. Using
(set-face-attribute 'highlight nil :background 'unspecified)
(set-face-attribute 'italic nil :slant 'unspecified)
in the above recipe produces the same result, i.e. doesn't
change the default for new frames.
I think I understand why.
Emacs actually has two places to get the face specifications
for new frames. There is face-new-frame-defaults, and there
is whatever the defface specified.
The face-new-frame-defaults are merged in by
Finternal_merge_in_global_face, and normally override what
the defface specified. But this happens only when the value
in face-new-frame-defaults is not `unspecified'.
In other words, setting an attribute to `unspecified'
has an inconsistent meaning. For an existing frame, it overrides
both the face-new-frame-defaults and the defface. But when
applied to the "default for new frames", it really means that
face-new-frame-defaults should no longer override the defface.
This is rather ugly, but I am not sure what to clean it up with.
That helps me understand. It seems very complex. I think I follow you, but I
don't understand it well enough to propose any solution. I think part of
what confuses me is the notion of a default value for a face (e.g. for
future frames). I'm still a bit confused about the behavior of :inherit and
nil wrt defining/undefining such a default value - and the role, if any, of
`unspecified' in this regard. (That probably makes no sense, but it
indicates my confusion.)
Anyway, given that I'm a bit confused, and you seem to understand the
problem I raised, I'll bow out now. Thanks for looking into this.
- Re: problems with face-spec-reset-face and set-face-attribute, (continued)
- Re: problems with face-spec-reset-face and set-face-attribute, Richard M. Stallman, 2005/10/10
- RE: problems with face-spec-reset-face and set-face-attribute, Drew Adams, 2005/10/11
- Re: problems with face-spec-reset-face and set-face-attribute, Richard M. Stallman, 2005/10/13
- RE: problems with face-spec-reset-face and set-face-attribute, Drew Adams, 2005/10/13
- Re: problems with face-spec-reset-face and set-face-attribute, Richard M. Stallman, 2005/10/14
- Re: problems with face-spec-reset-face and set-face-attribute, Eli Zaretskii, 2005/10/20
- Re: problems with face-spec-reset-face and set-face-attribute, Juri Linkov, 2005/10/20
- Re: problems with face-spec-reset-face and set-face-attribute, Eli Zaretskii, 2005/10/20
- RE: problems with face-spec-reset-face and set-face-attribute, Drew Adams, 2005/10/20
- Re: problems with face-spec-reset-face and set-face-attribute, Richard M. Stallman, 2005/10/23
- RE: problems with face-spec-reset-face and set-face-attribute,
Drew Adams <=
- Re: problems with face-spec-reset-face and set-face-attribute, Richard M. Stallman, 2005/10/23
- Re: problems with face-spec-reset-face and set-face-attribute, Richard M. Stallman, 2005/10/14
- RE: problems with face-spec-reset-face and set-face-attribute, Drew Adams, 2005/10/14
- Re: problems with face-spec-reset-face and set-face-attribute, Juri Linkov, 2005/10/15
- Re: problems with face-spec-reset-face and set-face-attribute, Richard M. Stallman, 2005/10/16