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
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
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
Could be, but all the font-lock levels I've seen don't do me any good: they
allow me to choose between coarse and fine highlighting, not between
fruit-salad and sobriety. I want sober fine highlighting.
You have lost me.
___
Setting the value to the face `default' (which produces the desirable
visual effect) is not exactly the same as a nil value.
When you say it is not exactly the same, could you explain what that
means? The two values are not eq, of course--is that what you mean?
Or are you referring to a
The simplest fix would be to specify a non-nil default.
Would someone who has a feel for choosing faces
please do that?
delphi-other-face is placed on way too many things which are (to my taste)
better left un-highlighted. So I think a default of nil is the
right
Richard M. Stallman wrote:
Setting the value to the face `default' (which produces the desirable
visual effect) is not exactly the same as a nil value.
When you say it is not exactly the same, could you explain what that
means? The two values are not eq, of course--is that what you
When redisplay merges faces a face `nil' won't have any effect on the previous
face. `default' will override the previous face with the default face.
In cases like
(add-text-properties start end (list 'face face-variable))
either `nil' or `default' will override the previous face.
--
Juri
Setting the value to the face `default' (which produces the desirable
visual effect) is not exactly the same as a nil value.
When you say it is not exactly the same, could you explain what that
means? The two values are not eq, of course--is that what you mean?
Or are you referring
When redisplay merges faces a face `nil' won't have any effect on the
previous face. `default' will override the previous face with the
default face.
In cases like
(add-text-properties start end (list 'face face-variable))
either `nil' or `default' will override the previous face.
But if
The simplest fix would be to specify a non-nil default.
Would someone who has a feel for choosing faces
please do that?
delphi-other-face is placed on way too many things which are (to my taste)
better left un-highlighted. So I think a default of nil is the
right choice.
Why not do what similar options, like `display-time-mail-face' do in
similar situations? I can install the trivial patch below if desired.
Because it is more complex, and is not helpful by default.
___
Emacs-pretest-bug mailing list
`delphi.el' has nil mismatch in:
(defcustom delphi-other-face nil
*Face used to color everything else.
:type 'face
:group 'delphi)
The simplest fix would be to specify a non-nil default.
Would someone who has a feel for choosing faces
please do that?
There
Richard Stallman wrote:
`delphi.el' has nil mismatch in:
(defcustom delphi-other-face nil
*Face used to color everything else.
:type 'face
:group 'delphi)
The simplest fix would be to specify a non-nil default.
Would someone who has a feel for
`delphi.el' has nil mismatch in:
(defcustom delphi-other-face nil
*Face used to color everything else.
:type 'face
:group 'delphi)
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
15 matches
Mail list logo
