emacs-pretest-bug
[Top][All Lists]
Advanced

[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)




reply via email to

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