bug#13686: hi-yellow vs. hi-lock-1

[David Koppelman <koppel@ece.lsu.edu>]

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