[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: |
Richard M. Stallman |
Subject: |
Re: problems with face-spec-reset-face and set-face-attribute |
Date: |
Thu, 13 Oct 2005 00:53:18 -0400 |
1. The statement about the behavior of nil and t for set-face-attribute is
apparently not true for attribute :inherit, but it is true for the other
attributes. The doc for set-face-attribute specifically mentions support for
:inherit, without saying anything special about it.
It is supposed to be true for all attributes.
Why do you say this is not true for :inherit?
Perhaps there is a bug.
2. Apparently, the set-face-attribute behavior also depends on what value
the attribute is set to: setting it to (pseudo-)value nil changes (resets)
its default value for future frames; setting it to another value apparently
does not.
If this is true, it is a bug. It is supposed to affect future frames
when FRAME is nil or t. Otherwise it should never do so.
3. The value `unspecified' is not very clear to me, but I don't have time
now to look up where it is documented. A default value of `unspecified', by
its _name_, would seem like it should have the behavior that apparently only
nil gives. Or is that just for :inherit?
This is documented in the Lisp manual. Is that documentation clear?
If not, could you point out what in the Lisp manual is unclear?
If you find a case whose behavior does not match the manual,
could you please report that as a bug?
4. set-face-attribute is implemented with internal-set-lisp-face-attributes.
That internal function has the clearest doc string of the three! Its
treatment of nil and t is different (and somewhat backward) from their
treatment by set-face-attribute: nil means change the attribute for the
selected frame; t means change its default value, for new frames; 0 means
change its value on all existing frames and its default value for new
frames. nil for set-face-attribute translates to 0 for internal-set*; t
remains t; a real frame is passed along.
It is somewhat unclean that internal-set-lisp-face-attributes
does not follow the same convention as set-face-attribute,
but since internal-set-lisp-face-attributes is not meant for users,
it is not a real problem.
6. What is the point (use case) of face-spec-reset?
I don't see any face-spec-reset in frame.el.
Do you mean face-spec-reset-face?
It is meant for use by face-spec-set.
And I don't see :inherit mentioned anywhere as an exception.
That's because it isn't one.
And I don't see nil mentioned in its special role for default (future)
values, although that might be done somewhere else in the doc.
That's because it does not have such a role.
- RE: problems with face-spec-reset-face and set-face-attribute, Drew Adams, 2005/10/09
- Re: problems with face-spec-reset-face and set-face-attribute, Juri Linkov, 2005/10/10
- 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 <=
- 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, 2005/10/23
- 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