Re: delphi-other-face mismatch

[martin rudalics]

> Perhaps we should define nil as a face that has no attributes.
> Then it would work to set any face-valued variable to nil.
> What do people think of that?
>
>

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.  Let's call this set
FACE.  If FACE is empty the display engine interprets the semantics of
FACE as

- have no impact on displayed text,

- display text with default face,

- do something more complicated, for example, in the context of mode or
  header lines.

As far as I can tell, the display engine fail-softly accepts virtually
anything whenever it attempts to retrieve FACE.  In particular, it
accepts the value nil which makes it possible to specify an empty FACE
in a more comfortable way because I don't have to care about the
identifying information mentioned above.

Now `face' is also a "customization type" used in `defface' and in
`defcustom ... :type 'face'.  With defface I directly assign FACE to a
variable.  Writing nil as value in a defface has Emacs construct an
appropriate vector with the identifying information only.  It does not
set the variable to nil.  When I customize that variable I can make FACE
empty by not checking anything.  With defcustom I indirectly assign FACE
to some variable.  In practice this means that I can make some FACE
empty with defcustom exclusively by referencing a variable that has been
defined with defface and has no attribute set.  But such a variable need
not exist.

Some designers require a defcustom that should define a face with no
attributes.  To resolve this conflict one could

- use ":type '(choice (const :tag "None" nil) face)" (proposed by Luc),
  which would require to change some 60 defcustoms within Emacs,

- allow the field remain empty (proposed by Juri), which would require
  to change customize and its user interface,

- implicitly change the semantics of ":type 'face" to something like
  ":type 'face-or-nil" (one interpretation of Richard's proposal), which
  would require to change customize only,

- 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.