Re: AW: Same coloring as GNU Emacs not possible due to fewer face types
On Thu, 05 Dec 2002, stephen(a)xemacs.org wrote:
>>>>> "Jeff" == Jeff Mincy
<jeff(a)delphioutpost.com> writes:
Jeff> But there are other applications like dired that has
Jeff> sockets, executable files, links (etc). How would you
Jeff> combine 'dired' faces with the 'language' faces?
On the one hand, `set-face-parent' comes to mind. On the other, I can
imagine shell buffers using those faces, too, when ls-ing. I can even
imagine synfl (syntactic font-locking) highlighting which recognizes
"stdin" in a cc-mode buffer and colors it "FILE *".
Ok, you might be on to something
But I can imagine lots of other things - like when you do sed -e
"blah" at a shell prompt that "blah" is in sed-script-mode and when
you
do (regexp "blah") that "blah" is in regexp-string-mode and (at
least)
highlights the control characters differently from the rest of the
stuff. And when you do diff, or cvs diff at a shell prompt then the
output comes out in diff-mode.
What I would like to see is a hierarchy like this:
Physical faces Logical faces
italic emphasis
red warning
sans serif-blue-on-black socket
App-specific faces should not be created. Instead, there should be a
face registry, and apps should define a specifier tag and use buffer
locales (it should be possible to have mode locales, I think, which
would simplify things enormously) to install face specs on existing
faces wherever possible.
You're losing me here. How would buffer locales, or even mode locales
simplify the rats nest proliferation of faces? Haven't you just
shifted the problem from the definition of application specific
faces to the specification of a mode-specific specifier locales? (Yow)
The examples you gave for physical faces 'italic' and 'red' are
'pure' face where you have specified just one face dimension
(font-slant vs foreground). The 'sans serif-blue-on-black' physical
face is a 'composite' face where you have specified the foreground and
background and partially specified the font.
Mapping a logical face 'warning' to 'red' is fine, and even logical,
but having physical faces like 'sans serif-blue-on-black' seems to be
going down the same path that lead to the proliferation of faces in
the first place. Maybe I don't understand specifiers and what
you mean by specifier tags. But, I'm assuming that you really mean a
multiple inheritance scheme where a logical face can inherit
attributes from multiple other logical and physical faces eg
(define-face socket (sans-serif blue on-black))
This is of course just dreaming, as GNU Emacs can't do this. :-(
What can't gnu emacs do? set-face-parent or the specifier tags?
If you come up with something that is truly a simplification, then it
could be more than just dreaming.
Speaking of dreaming, we should probably move the conversation to
a different mailing list?
-jeff