GNU bug report logs -
#13686
24.3.50; Re-look hi-lock-face-defaults (aka Provide more "core" faces for highlighting)
Previous Next
Reported by: Jambunathan K <kjambunathan <at> gmail.com>
Date: Mon, 11 Feb 2013 06:16:02 UTC
Severity: wishlist
Found in version 24.3.50
Done: Jambunathan K <kjambunathan <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Jambunathan K <kjambunathan <at> gmail.com>
>
> Let's focus on core, themable faces. How many you want in what prefix
> or file. I propose that these faces be named opaquely as
> hi-lock-N
> highlight-N
> font-lock-user-N
> font-lock-highlight-N
> font-lock-extra-face-N
I object to using cryptic names for faces. The user should see a
recognizable color name for the default hi-lock faces, and should be
able to pick any face he or she likes. Hi-lock currently does this. I
know that this can be achieved using face names such as hi-lock-1 by
extracting a color from a face definition (if necessary, mapping an
RGB triple to a name), but this is an unnecessary complication. As I
see it, the only things that will be achieved are providing for
themability and abiding by a convention that some interpret as a
separation of face attributes from face names.
I still don't understand why themability is so important for someone
who wants to quickly highlight things for their own purposes. This is
not the same as having a face reserved for errors, warnings, etc.
As for the convention of not naming or otherwise linking a face with
particular attributes (as some may interpret it), either it doesn't
apply here, or if it does, it's a good place to ignore it. I've argued
before that it does not apply because as most agree faces should be
defined for a particular purpose rather than for appearance, such as
for highlighting variable names. The face hi-yellow has a purpose:
highlight something with a background of yellow. It is named
appropriately and its attributes are so set. If there is a rule
somewhere which clearly states that this is not allowed, then that
rule should be broken in this case.
This bug report was last modified 11 years and 189 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.