[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: delphi-other-face mismatch
From: |
martin rudalics |
Subject: |
Re: delphi-other-face mismatch |
Date: |
Sat, 10 Sep 2005 10:06:47 +0200 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
Thanks for the patient explanations.
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?
I needlessly complicated things here. All I wanted to say is that the
display engine handles
(defface face nil
"Nil face.")
(put-text-property (line-beginning-position) (line-end-position) 'face 'face)
and
(put-text-property (line-beginning-position) (line-end-position) 'face nil)
much the same way.
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)
The problem is that routines dealing with faces seem to interpret nil in
a special way. On my Emacs having a face nil may break `customize-face'
with point before a default face character. In this case customize-face
proposes as default "nil" instead of "all faces". Customizing nil gives
me a strange empty "*Customize Faces*" buffer.
Moreover `describe-face' sometimes describes the face nil when there are
other face properties for the character after point. Probably these
behaviors could be resolved easily within `read-face-name' - if someone
can reproduce them.