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

[Jambunathan K]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The main point is that it makes little sense for a face, which is
>> a variable thingy (changeable, customizable), to have a name that
>> suggests otherwise, i.e., suggests that it has some _particular_,
>> constant quality.
>
> If the user sets the hi-yellow face to red, she gets what she deserves.

As an intelligent user, she deserves better.  I am not asking for
*supplanting* the status quo but to *augment* it.

>> The face name should reflect what the face is for - the kind of
>> highlighting or whatever that it does.
>
> Agreed, and hi-yellow is for highlighting some text in yellow, hence
> its name.
>
> The only real problem is that a user who wants to use a face whose
> attribute do not agree with any of the predefined hi-* faces might end
> up forced to use such a silly setting.
>
> So the right fix is to provide ways for the user to add her own faces.
>
> An alternative might be to let the user specify either a face name or
> a color name, so we can get rid of hi-yellow altogether.  But that still
> only caters to "highlighting with a color", whereas faces offer
> more choices.

Having a *set* of faces for highlighting and have them recognized as
"core" faces will make theme designers conscious of their presence and
usefulness.

Consider the case for ido.  At the minibuffer prompt, I see atleast
three faces (leaving aside the default face).

1. The minibuffer prompt itself.
2. The first match face.
3. Face for directories.

The important thing is that these faces should not only be contrasting
enough but also harmonious.  If I am not happy with the default faces
for ido, I can simply make the ido faces inherit highlight, highlight-1,
highlight-2 etc and be done with it.

>         Stefan
>
>
>
>

--