[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: delphi-other-face mismatch
From: |
Richard M. Stallman |
Subject: |
Re: delphi-other-face mismatch |
Date: |
Sat, 03 Sep 2005 05:06:53 -0400 |
Just to make things clear for myself: An Elisp `face' is not a primitive
type like say `integer' or `overlay'. It's merely a set of attributes
stored, together with some identifying information, in a vector which is
interpreted by the display engine in a special way.
That data type is used internally, but the faces that Lisp programs
normally operate on are symbols.
If FACE is empty the display engine interprets the semantics of
FACE
I am not sure what situation you're talking about. Where in the data
structure was nil encountered?
Now `face' is also a "customization type" used in `defface' and in
`defcustom ... :type 'face'.
It expects the value to be a symbol, but it displays the appearance
of that symbol.
With defface I directly assign FACE to a
variable.
No, defface does not set the value as a variable. It defines a symbol
with the `face' property which defines it as a face.
- defface a new face "nil" with no attributes and have defcustom refer
to that face (another interpretation of Richard's proposal), which
would require to change the semantics of nil (in the context of faces
only).
The first three don't address the problem that nil is not a valid value
for a variable storing FACE. The fourth does but I can't imagine how to
implement it.
How about this?
(defface nil nil
"Face which specifies no attributes."
:group 'basic-faces)