bug#13686: 24.3.50; Re-look hi-lock-face-defaults (aka Provide more "core" faces for highlighting)

bug#13686: 24.3.50; Re-look hi-lock-face-defaults (aka Provide more "core" faces for highlighting)

[Jambunathan K]

Spun-off from 
        http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11095

Bug pertains to the variables mentioned below.  (CAUTION: Don't look at
the bug, you will be lost)

,----
| (defvar hi-lock-face-defaults
|   '("hi-yellow" "hi-pink" "hi-green" "hi-blue" "hi-black-b"
|     "hi-blue-b" "hi-red-b" "hi-green-b" "hi-black-hb")
|   "Default faces for hi-lock interactive functions.")
`----

,----
| (defface hi-yellow
|   '((((min-colors 88) (background dark))
|      (:background "yellow1" :foreground "black"))
|     (((background dark)) (:background "yellow" :foreground "black"))
|     (((min-colors 88)) (:background "yellow1"))
|     (t (:background "yellow")))
|   "Default face for hi-lock mode."
|   :group 'hi-lock-faces)
`----



Proposal in Elisp
-----------------

My proposals amounted to this patch and 

        http://debbugs.gnu.org/cgi/bugreport.cgi?msg=8;filename=bug11095-part1.patch;att=1;bug=11095

A variation of above changes from my .emacs.  (WARNING: May contain
irrelevant bits.  Reader discretion advised.)

,----
| 
| (defface hi-lock-1
|   '((t (:background "#ffff00" :foreground "black")))
|   "Face for hi-lock mode."
|   :group 'hi-lock-faces)
| 
| (defface hi-lock-2
|   '((t (:background "#00ff7f" :foreground "black")))
|   "Face for hi-lock mode."
|   :group 'hi-lock-faces)
| 
| 
| (setq hi-lock-face-defaults
|       (mapcar 'face-name
| 	      '(hi-lock-1 hi-lock-2 hi-lock-3 hi-lock-4 hi-lock-5 hi-lock-6
| 			  hi-lock-7 hi-lock-8 hi-lock-9 )))
| 
| (custom-set-variables 
|  '(hi-lock-faces 
|    (quote (hi-lock-1 hi-lock-2 hi-lock-3 hi-lock-4 hi-lock-5
| 		     hi-lock-6 hi-lock-7 hi-lock-8 hi-lock-9))))
`----


Various voices (Stefan, Jambu, Drew)
-----------------------------------

,----
| 1) Review the face names used in `hi-lock-face-defaults' and make the
|    faces customizable.  The defaults may not look good on a user's his
|    own font-lock configuration.
`----

,----
| > > -(defface hi-yellow
| > > +(defface hi-lock-1
| > 
| > I'm not sure it's an improvement.  When choosing a face in
| > hi-lock-face-buffer, "hi-lock-1" doesn't speak much to me contrary to
| > "hi-yellow".
| 
| Not specifically related to this face, but it is a bad idea, in general (no
| doubt there are exceptions), for a face name to advertize particular face
| attributes, such as the color.
| 
| The color is presumably something that the user can customize, and is typically
| not something that speaks to the use or meaning of the face.
`----

,----
| I think the real issue here is that hi-lock should have a customizable
| set of faces rather than a set of customizable faces.
| So if the user doesn't like hi-yellow (which should be called
| hi-lock-yellow, BTW) because she never highlights in yellow, she can
| replace it with her own face with the name she likes.
`----

,----
| 1. I want the name to be opaque and semantic.
| 
| 2. I also want a pre-defined set of faces for highlighting apart from
|    the one "core" highlight face.  I think there are 9 hi-* faces and
|    these numbers are good enough.
| 
|    Think of them as extra colors in my palette.
| 
|    Having a set of highlighting faces will help in theming.  For
|    example, consider finding file in ido-mode.  When I do C-x C-f, I see
|    various faces - the minibuffer prompt, ido-first-match, ido-subdir,
|    ido-indicator all occurring /next/ to each other.  If there are
|    hi-lock-N faces, chosen by a theme designed, one can simply have ido
|    faces inherit from these themed faces.  It is much cleaner.
| 
|    Remember choosing faces that can co-exist in buffer without much
|    trouble to eyes is challenging task - one needs to balance harmony
|    and contrast.  A theme designer is likely to work with a palette and
|    can go with color-picking techniques like triad, tetrad schemes.  See
| 
|         http://colorschemedesigner.com/
|         http://www.w3.org/wiki/Colour_theory
|         http://packages.debian.org/squeeze/agave
| 
|    Triad and tetrads apparently are colors that are 120 and 90 degrees
|    apart in the color wheel.  So if there are N highlighting faces, they
|    can be spaced 360/N degree apart in a color wheeel.
| 
|    Drew's reasoning that it is the N-th highlighting face in a sequence.
| 
| 3. Configuring an yellow face in red is a bit ugly.  It is declaring a
|    variable name FALSE that is assigned a variable value true.
| 
| >> Just why would you prefer a "customizable set of faces" over a "set of
| >> customizable faces"?  And how does that relate to the names?
| >
| > Because the user can then choose the names that make sense to her.
| 
| While reading a face name from minibuffer, if the face name itself is
| highlighted in that face - think rainbow mode - then the name of the
| face shouldn't matter.
| 
| What you are asking for is a constant face whose properties don't change
| at all.  One can have an elpa packages which provides constant faces,
| that are immediately useful.
| 
`----





In GNU Emacs 24.3.50.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2013-02-11 on debian-6.05
Bzr revision: 111730 rgm@gnu.org-20130211015045-19w1ceor0tkfxc8q
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
System Description:	Debian GNU/Linux 6.0.5 (squeeze)

bug#13686: 24.3.50; Re-look hi-lock-face-defaults (aka Provide more "core" faces for highlighting)

[Stefan Monnier]

hi-lock.el lists David Koppelman as author (and maintainer for lack of
any other indication).  I don't know if David is really still
maintaining it, but otherwise maybe you could take over maintainership
of this package?


        Stefan

bug#13686: 24.3.50; Re-look hi-lock-face-defaults (aka Provide more "core" faces for highlighting)

[David Koppelman]

I'm still willing to maintain it. I wasn't aware of the bug
report, but I'll look into it.

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

> hi-lock.el lists David Koppelman as author (and maintainer for lack of
> any other indication).  I don't know if David is really still
> maintaining it, but otherwise maybe you could take over maintainership
> of this package?
>
>
>         Stefan

bug#13686: 24.3.50; Re-look hi-lock-face-defaults (aka Provide more "core" faces for highlighting)

[Stefan Monnier]

> I'm still willing to maintain it.

Oh, great.

> I wasn't aware of the bug report, but I'll look into it.

Yes, sorry: we should improve our handling of bugs (and commit messages)
to keep maintainers better informed.


        Stefan

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

[David Koppelman]

As the original developer of hi-lock and one willing to continue
maintaining it, let me add my voice:

I feel that a face name like hi-lock-1 would be much less useful, even
if the name itself were rendered with the highlighting. The user's
goal is to highlight something, currently the user can go through
face choices until he or she finds a suitable color (if the first one
does not satisfy). A cryptic name like hi-lock-1 just puts irrelevant
information in front of the user, assuming the name is highlighted
with the color.

A name like font-lock-comment-face is semantic because it indicates
the purpose of the face.  The purpose of hi-yellow is to highlight
something in yellow, so in that sense the name is semantic.

If themers felt a strong need, we could make hi-lock-face-defaults
themable so that hi-yellow and hi-green say, could be replaced with
hi-golden-honey and hi-grassy-green. (Or the original face names with
slightly different tints.)

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

[Drew Adams]

The face name should not reflect any particular face attributes - not, that is,
unless the attributes are somehow made to remain relatively constant (e.g.
always some shade of yellow).

Or if there is only one face for a given feature/library, and there is no more
appropriate name, then it can make sense to name the face after the
feature/library, for purposes of discoverability etc.

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.

The face name should reflect what the face is for - the kind of highlighting or
whatever that it does.  Is this all we can say about the purpose of this face?

  > The user's goal is to highlight something

That's pretty vague, but at least "highlight" presumably belongs in the name.
(No, not all faces are for highlighting.)  And if you can narrow down the kind
of "something" or the use of the highlghting, then that info too can help.

Presumably, this highlighting of something is hi-lock highlighting.  That
already makes it a specific kind of highlighting.  There is a specific way to
turn it on/off etc.

The manual says that hi-lock-mode highlights text that matches a regexp you
provide.  Is this face used for that highlighting?

If so, and if there is not some other hi-lock face that it could be confused
with, then "hi-lock" in the face name is the best identification of what it is
for: it is the face for hi-lock highlighting.

If hi-lock uses other faces that are not for highlighting, then add "highlight"
to the name.  If hi-lock has multiple faces used for highlighting in essentially
the same way, i.e., there is nothing other than their separateness that
distinguishes them, then yes, "hi-lock-1", "hi-lock-2", etc. are the best names.

IOW, if you cannot be more specific than to say that this is for hi-lock
highlighting, then hi-lock highlighting is what the name should reflect.

It certainly should not reflect the face's particular default attributes,
whether they be underlining, boxing, or a yellow background.

> the user can go through face choices until he or she finds
> a suitable color (if the first one does not satisfy)

By that I guess you mean choosing among the available hi-lock faces, e.g., by
cycling.  Nothing wrong with that.

But the current appearance of each of those faces has nothing to do with the
face names you currently use: "hi-green" etc.  Face `hi-green' might well mean
italic blue text on a pink background and wrapped in a box.

You seem to be arguing that a name like "hi-green" helps the user by suggesting
the appearance (e.g. green background or foreground) s?he will get.  Nothing
could be farther from the truth.  It misleads the user into thinking precisely
that.

If you want to give the user names that describe appearance, then you don't want
faces, which are variable, you want constants - e.g., symbols or strings.

In that case, let users choose a _color name_ for each kind of highlighting that
you make available, and set the color of the face for that highlighting to the
chosen color.  Simple.  The user sees color names as the choices (and all
available color names, not just 5 or 6).

In that case, you need to decide which attribute(s) of the face to use that
color for: foreground, background, underline, box.  Or you need to somehow let
users choose the attribute(s) too.

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

[Stefan Monnier]

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

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


        Stefan

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

[Jambunathan K]

David Koppelman <koppel@ece.lsu.edu> writes:

> As the original developer of hi-lock and one willing to continue
> maintaining it, let me add my voice:
>
> I feel that a face name like hi-lock-1 would be much less useful, even
> if the name itself were rendered with the highlighting. The user's
> goal is to highlight something, currently the user can go through
> face choices until he or she finds a suitable color (if the first one
> does not satisfy). A cryptic name like hi-lock-1 just puts irrelevant
> information in front of the user, assuming the name is highlighted
> with the color.

New option `hi-lock-auto-select-face' makes selection of faces
redundant.  So with auto-selection on, one doesn't even have to pick.
One merely gets on with one's business of making sense of code/text at
hand.

Here is my original use-case

,---- http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11095
|
| 2) Make `hi-lock-face-buffer' use a different face on each invocation.  
| 
|    Here is a real-world usecase for the above request.
| 
|    As a programmer, I use highlighting to trace variable dependencies
|    within a function.  For example, in the example below, after
|    highlighting the variables in __different__ faces, I will come to the
|    conclusion that "a" depends on "d" and "tmp".
| 
|      c = d;
|      b = c + tmp;
|      a = b;
| 
|    And I use this very often to track variables and how they get their
|    values from.
| 
|    If I were to use the default Emacs provided behaviour then I would
|    have to press M-n multiple times as I highlight more and more
|    symbols. (Typically I have 3-5 symbols highlighted before I turn off
|    highlighting.)
|
`----

> A name like font-lock-comment-face is semantic because it indicates
> the purpose of the face.  The purpose of hi-yellow is to highlight
> something in yellow, so in that sense the name is semantic.

In would consider `hi-yellow' a "constant" face.  I am not questioning
the usefulness or rationale of original choice - I am convinced that it
is useful.  

I am merely presenting one another use-case.  We can have both constant
faces and themable faces.  IIRC, my original patch defaliased the
hi-yellow to hi-lock-1.

> If themers felt a strong need, we could make hi-lock-face-defaults
> themable so that hi-yellow and hi-green say, could be replaced with
> hi-golden-honey and hi-grassy-green. (Or the original face names with
> slightly different tints.)

This seems like a half-hearted attempt at theming.

Remember, `highlight' face which is one of the "core" faces.  My
suggestion could be considered as a case for augmenting the highlighting
faces with more numbers and have someone who is "visually adept" choose
good defaults.

The need for theming - that is multiple highlighting faces to *co-exist
simulataneously* in one's buffer - is very important.  When I have 3-4
highlights in my buffer (using the current defaults) my eye hurts.

Bottomline: It is not an "one-or-the-other" proposal.  Let's have best
of both worlds.
-- 

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

[Jambunathan K]

"Drew Adams" <drew.adams@oracle.com> writes:

> "hi-lock-1", "hi-lock-2", etc. are the best names.

My earlier mail asked for making the highlighting face a "core" one.  So
having highlight-1, highlight-2 etc as "core" themable faces will make
theme designers pay attention to it.

From a theming perspective, the sequence 1, 2 etc are not merely opaque
names.  I have argued that they can be look at as "angles" on a "color
wheel".

So if we are looking at triads of colors, we are looking at colors at
positions n * 120 degrees apart on a color wheel.

The colors of highlight faces *should not* be chosen independently.
They should "gel" well with each other.  
-- 

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

-- 

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

[Jambunathan K]

David Koppelman <koppel@ece.lsu.edu> writes:

> A name like font-lock-comment-face is semantic because it indicates
> the purpose of the face.  

Instead of hi-lock-n or highlight-n, one can go for
font-lock-highlight-face-1, font-lock-hihglight-face-2 etc.

If one is working on a new programming mode and wants an "extra face" in
his palette then one knows what can be picked.
-- 

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

[Drew Adams]

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

Really?  What dos she deserve?  Are you saying that there is some reason she
should not customize the face?  Why use a face then?

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

If that's really what it's for, then the name is apt.

In that case, a customizable face is not what's needed.  Or else maybe one where
you somehow limit the customization regarding color for various attributes.

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

If you provide a customizable face where you don't want one, and you don't limit
it in any way, that's the silliness.  It is not silly for a user to use an
allowed value.
 
> So the right fix is to provide ways for the user to add her own faces.

That would not change the anomalous `hi-<color>' faces.  It would not prevent
the silly settings you mention.

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

Let the user choose a color.  And let the user choose other attributes.

And if you're going to do all that, then just let the user customize faces,
which do not have any static, inherent colors, even if they might unfortunately
have a color in their names.

IOW, just rename the faces based on what they are really for, not on particular
colors.

Oh, but you said that "hi-yellow is for highlighting...in yellow".  In that
case, it is not also about using other face attributes.  Time to choose.

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

[Jambunathan K]

"Drew Adams" <drew.adams@oracle.com> writes:

> Oh, but you said that "hi-yellow is for highlighting...in yellow".  In
> that case, it is not also about using other face attributes.  Time to
> choose.

`hi-yellow' is an example of a face that is immutable.  It is
defconstface, so to speak.
-- 

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

[Drew Adams]

> > Oh, but you said that "hi-yellow is for highlighting...in 
> > yellow".  In that case, it is not also about using other face 
> > attributes.  Time to choose.
> 
> `hi-yellow' is an example of a face that is immutable.  It is
> defconstface, so to speak.

As I said before, and at the very beginning as well, I believe: if it were in
fact constant then such a name might be apt.

Is it in fact immutable?  I didn't think so, and I see nothing in the code that
prevents changing it.  On the contrary, it seems to be a normal, customizable
face.

And that's the point.  `hi-yellow' is not a great name for a customizable face.

(And if it were truly immutable then there would be more that is constant about
it than just its yellow color.  Whether the name should then reflect only
"yellow" could be based on whether the color were the most important constant
attribute.)

If you really want an immutable face with some yellow attribute(s), then enforce
that in the code.  If you instead define a normal face  (i.e., customizable,
with no restrictions) then don't confuse users by calling it "yellow" - because
it's not.

Just one opinion, of course.

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

[Jambunathan K]

"Drew Adams" <drew.adams@oracle.com> writes:

> (And if it were truly immutable then there would be more that is constant about
> it than just its yellow color.  Whether the name should then reflect only
> "yellow" could be based on whether the color were the most important constant
> attribute.)

In lighter vein, I still remember the old days when I looked at
"hi-yellow" and thought that it was a "very bright yellow" and searched
for "lo-yellow".

No, I am not making the above story up.

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

[Drew Adams]

> In lighter vein, I still remember the old days when I looked at
> "hi-yellow" and thought that it was a "very bright yellow" 
> and searched for "lo-yellow".
> 
> No, I am not making the above story up.

;-)

Not very important, but is there a reason why the prefix `hi-lock-' is not used
here as elsewhere?  (And perhaps it should be added to the defgroup.)

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

[Stefan Monnier]

>> "hi-lock-1", "hi-lock-2", etc. are the best names.
> My earlier mail asked for making the highlighting face a "core" one.  So
> having highlight-1, highlight-2 etc as "core" themable faces will make
> theme designers pay attention to it.

We could definitely add such core faces.  But in order for that to
augment current functionality, we still need a way for the user to
specify the highlighting directly by its attribute.


        Stefan

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

[Jambunathan K]

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

>>> "hi-lock-1", "hi-lock-2", etc. are the best names.
>> My earlier mail asked for making the highlighting face a "core" one.  So
>> having highlight-1, highlight-2 etc as "core" themable faces will make
>> theme designers pay attention to it.
>
> We could definitely add such core faces.  But in order for that to
> augment current functionality, we still need a way for the user to
> specify the highlighting directly by its attribute.

The last sentence after the comma is not clear to me.  You seem to imply
some-"way" is missing.  Can someone explain what is meant here?

>         Stefan

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

[Stefan Monnier]

>>>> "hi-lock-1", "hi-lock-2", etc. are the best names.
>>> My earlier mail asked for making the highlighting face a "core" one.  So
>>> having highlight-1, highlight-2 etc as "core" themable faces will make
>>> theme designers pay attention to it.
>> We could definitely add such core faces.  But in order for that to
>> augment current functionality, we still need a way for the user to
>> specify the highlighting directly by its attribute.
> The last sentence after the comma is not clear to me.  You seem to imply
> some-"way" is missing.  Can someone explain what is meant here?

I meant "in hi-lock".  More specifically, the current hi-lock lets you
choose a face name, not a color.  Since current face names include
"hi-yellow", it ends up letting you choose a color, but if we rename
them to something else, that removes this (indirect) ability to specify
a color.


        Stefan

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

[Juri Linkov]

> And that's the point.  `hi-yellow' is not a great name for a customizable face.

`hi-yellow' is a meaningful name.  Together with other complementary
faces they cover the whole color space.  If you don't want the default
yellow color, you can customize it to another shade of yellow,
e.g. "Light Goldenrod Yellow".  If you want a shade of green,
customize `hi-green' and use it, etc.

OTOH, face names like `hi-lock-1' or `hi-lock-2' are meaningless.
What does the number 1 or 2 mean?  Compare them with other faces
that have a number in their names where the number in `info-title-1',
`gnus-cite-1', `outline-1', `org-level-1' means the nesting level.

What could be improved is `hi-lock-face-defaults' to specify
a color palette like in `vc-annotate-color-map' that produces
such color gradient face names as `vc-annotate-face-DDFF3F'
(note that the hex number "DDFF3F" is still meaningful in the face name).

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

[Jambunathan K]

Juri Linkov <juri@jurta.org> writes:

>> And that's the point.  `hi-yellow' is not a great name for a customizable face.
>
> `hi-yellow' is a meaningful name.  Together with other complementary
> faces they cover the whole color space.  

It is difficult for me to believe that the original design intent was to
"cover color space".

    hi-black-b
    hi-black-hb
    hi-blue
    hi-blue-b
    hi-green
    hi-green-b
    hi-pink
    hi-red-b
    hi-yellow

You see there are two blacks, two blues and two greens. Try

        C-u M-x list-colors-display RET hi- RET

and convince yourself how close or far away it is from covering the
whole "color space".  It seems like a mixed bag.  If there is a design,
I am not seeing it.

But your suggestion that the colors should distributed on the color
wheel sounds appealing.  I propose:

1. hi-lock-color-* prefix for these faces and add more colors.  How many
   do you want.  8 or 12 would be a good start.

   http://en.wikipedia.org/wiki/Html_colors#HTML_color_names
   http://en.wikipedia.org/wiki/Html_colors#X11_color_names


ps:  I know how to alias faces.  But how do I obsolete faces.

Can someone hammer out the fine details for me?  Should be copy-pasta
work once there is some consensus or agreement.

> If you don't want the default yellow color, you can customize it to
> another shade of yellow, e.g. "Light Goldenrod Yellow".  If you want a
> shade of green, customize `hi-green' and use it, etc.
>
> OTOH, face names like `hi-lock-1' or `hi-lock-2' are meaningless.
> What does the number 1 or 2 mean?  Compare them with other faces
> that have a number in their names where the number in `info-title-1',
> `gnus-cite-1', `outline-1', `org-level-1' means the nesting level.
>
> What could be improved is `hi-lock-face-defaults' to specify
> a color palette like in `vc-annotate-color-map' that produces
> such color gradient face names as `vc-annotate-face-DDFF3F'
> (note that the hex number "DDFF3F" is still meaningful in the face name).

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

[Jambunathan K]

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

>>> "hi-lock-1", "hi-lock-2", etc. are the best names.
>> My earlier mail asked for making the highlighting face a "core" one.  So
>> having highlight-1, highlight-2 etc as "core" themable faces will make
>> theme designers pay attention to it.
>
> We could definitely add such core faces.  But in order for that to
> augment current functionality, we still need a way for the user to
> specify the highlighting directly by its attribute.


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 have also proposed that hi-yellow etc be named as
hi-lock-color-yellow etc.

My overall plan is to have a formalized version of the following with
`hi-lock-face-regexp' turned around in to a defcustom.  

    (defvar hi-lock-face-regexp "\\`hi-lock-color")

    (setq hi-lock-face-defaults
          ((lambda (regexp)       
             "List of faces that match REGEXP."
             (delq nil
                   (mapcar (lambda (f)
                             (let ((s (symbol-name f)))
                               (when (string-match regexp s) f)))
                           (reverse (face-list))))) 
           hi-lock-face-regexp))

This way those who want to be prompted with colors and those who want
opaque, themable faces will remain happy.

ps: I will provide a patch once there is a general agreement on the
approach.

----------------------------------------------------------------

>
>
>         Stefan

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

[Jambunathan K]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > Oh, but you said that "hi-yellow is for highlighting...in 
>> > yellow".  In that case, it is not also about using other face 
>> > attributes.  Time to choose.
>> 
>> `hi-yellow' is an example of a face that is immutable.  It is
>> defconstface, so to speak.
>
> As I said before, and at the very beginning as well, I believe: if it were in
> fact constant then such a name might be apt.

From the "I-want-colors" camp, I am hearing that by Yellow it is not
yellow per-se but some variation of yellow.  

The definition of Yellow is so broad that it will go to the extent of
embracing face with a yellow background or even a reverse video of it.
Visually speaking, you will see Yellow - a light one or a bright one, in
either foreground or background etc.  Where yellow occurs is not
guaranteed, but you will get yellow.


> Is it in fact immutable?  I didn't think so, and I see nothing in the code that
> prevents changing it.  On the contrary, it seems to be a normal, customizable
> face.
>
> And that's the point.  `hi-yellow' is not a great name for a customizable face.
>
> (And if it were truly immutable then there would be more that is constant about
> it than just its yellow color.  Whether the name should then reflect only
> "yellow" could be based on whether the color were the most important constant
> attribute.)
>
> If you really want an immutable face with some yellow attribute(s), then enforce
> that in the code.  If you instead define a normal face  (i.e., customizable,
> with no restrictions) then don't confuse users by calling it "yellow" - because
> it's not.
>
> Just one opinion, of course.

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

[David Koppelman]

> From: Jambunathan K <kjambunathan <at> gmail.com>
>
> It is difficult for me to believe that the original design intent was to
> "cover color space".

There was no conscious effort to evenly cover the color space. The
idea was to choose colors that looked right for highlighting, with the
default set to background yellow, as is customary. Some faces are
provided as foreground-bold colors, and one as an alternate font.

I did not design hi-lock for automatically rotating faces and I
personally don't like automatic rotation for two reasons. First, it
assumes that the user wants a different color for each highlighting
pattern, which may often be the case, but not always. Second, I think
it's better when the user explicitly controls the color, so that there
is a better connection between the color and whatever it is the
targets signify.

That said, I don't object to re-selecting the colors to be more evenly
spaced perceptually. But, there should still be foreground-bold
variants.

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

[David Koppelman]

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

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

[Jambunathan K]

David Koppelman <koppel@ece.lsu.edu> writes:

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

Ok, I withdraw hi-lock-N.  As for other faces, I believe it is Stefan's
or Emacs maintainers call.  I am moving forward, after getting a
in-principle go from Stefan.

> 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 gave a code snippet at the end of the mail.  If you had looked at it,
you will realize that I have done nothing which changes the status quo
but I have done eveything to accommodate my requirements.  I am the
proposer, right?

Please provide specific feedback on the snippet rather than registering
a broad objection.  I have made an effort to understand the
"I-want-color" camp and I have also openly acknowledged that the
"I-want-color" camp have valid and sensible arguments.

Jambunathan K.

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

[David Koppelman]

Jambunathan K <kjambunathan@gmail.com> writes:
>
> I gave a code snippet at the end of the mail.  If you had looked at it,
> you will realize that I have done nothing which changes the status quo
> but I have done eveything to accommodate my requirements.  I am the
> proposer, right?

I'm sorry, I was responding more to past comments than the specific
message I was replying to.

> Please provide specific feedback on the snippet rather than registering
> a broad objection.  I have made an effort to understand the
> "I-want-color" camp and I have also openly acknowledged that the
> "I-want-color" camp have valid and sensible arguments.

So, the goal of hi-lock-face-regexp is to select a set of fonts. I
guess the custom interface would expose simple options to the user,
for example, "Fixed Colors", "Theme Colors", and for each option the
appropriate regexp would be assigned.  Is that right?

In that case, why not have a variable hi-lock-use-theme-colors and use
that to select either the current default list, or one with generic
names.

That said, I still believe the user should see the color that will be
applied, and that this be accomplished without undue complexity.

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

[Jambunathan K]

David Koppelman <koppel@ece.lsu.edu> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:
>>
>> I gave a code snippet at the end of the mail.  If you had looked at it,
>> you will realize that I have done nothing which changes the status quo
>> but I have done eveything to accommodate my requirements.  I am the
>> proposer, right?
>
> I'm sorry, I was responding more to past comments than the specific
> message I was replying to.
>
>> Please provide specific feedback on the snippet rather than registering
>> a broad objection.  I have made an effort to understand the
>> "I-want-color" camp and I have also openly acknowledged that the
>> "I-want-color" camp have valid and sensible arguments.
>
> So, the goal of hi-lock-face-regexp is to select a set of fonts. I
> guess the custom interface would expose simple options to the user,
> for example, "Fixed Colors", "Theme Colors", and for each option the
> appropriate regexp would be assigned.  Is that right?

Correct.

> In that case, why not have a variable hi-lock-use-theme-colors and use
> that to select either the current default list, or one with generic
> names.

Yes, this is fine with me.  I am open to anything that would address
even a fraction of my needs.

> That said, I still believe the user should see the color that will be
> applied, and that this be accomplished without undue complexity.

Yes, existing users of hi-lock shouldn't be alarmed with new changes.

Jambunathan K.

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

[Juri Linkov]

>> `hi-yellow' is a meaningful name.  Together with other complementary
>> faces they cover the whole color space.
>
> It is difficult for me to believe that the original design intent was to
> "cover color space".
>
>     hi-black-b
>     hi-black-hb
>     hi-blue
>     hi-blue-b
>     hi-green
>     hi-green-b
>     hi-pink
>     hi-red-b
>     hi-yellow
>
> You see there are two blacks, two blues and two greens. Try
>
>         C-u M-x list-colors-display RET hi- RET
>
> and convince yourself how close or far away it is from covering the
> whole "color space".  It seems like a mixed bag.  If there is a design,
> I am not seeing it.

When I try `C-u M-x list-faces-display RET hi- RET'
I see exactly the same colors as displayed in the first image
in http://en.wikipedia.org/wiki/RGB

Primary colors: hi-red-b, hi-green-b, hi-blue-b.
Secondary colors: hi-blue, hi-pink, hi-yellow.

So there is a complete coverage of the colors
evenly distributed on the color wheel.

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

[Stefan Monnier]

>> hi-lock-N
>> highlight-N
>> font-lock-user-N
>> font-lock-highlight-N
>> font-lock-extra-face-N

The "font-lock-<foo>" names are due to history.  There's no point using
this scheme for new faces, especially for faces not directly linked to
font-lock.

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

How 'bout designing a concise "face description" format, so that instead
of choosing "hi-yellow", the user can choose (say) "b:yellow",
"f:blue", or "s:bold".  This would give access to "any color", and in
order not to overwhelm the user, the completion would default to only
completing among a predefined set (corresponding to the current
predefined faces)?


        Stefan

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

[Jambunathan K]

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

>>> hi-lock-N
>>> highlight-N
>>> font-lock-user-N
>>> font-lock-highlight-N
>>> font-lock-extra-face-N
>
> The "font-lock-<foo>" names are due to history.  There's no point using
> this scheme for new faces, especially for faces not directly linked to
> font-lock.

David had reservations with introducing hi-lock-N.  I am not sure he
continues to hold this reservation.

For now, highlight-Ns for N=6 with highlight and highlight-1 aliased to
each other.

>> 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.
>
> How 'bout designing a concise "face description" format, so that instead
> of choosing "hi-yellow", the user can choose (say) "b:yellow",
> "f:blue", or "s:bold".  This would give access to "any color", and in
> order not to overwhelm the user, the completion would default to only
> completing among a predefined set (corresponding to the current
> predefined faces)?

So you are steering the discussion exactly to the opposite extreme.
What is your motivation here.  Where do you think jit named-faces could
be useful, apart from highlighting case.

>         Stefan

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

[Stefan Monnier]

> David had reservations with introducing hi-lock-N.  I am not sure he
> continues to hold this reservation.

And I tend to agree with him

> For now, highlight-Ns for N=6 with highlight and highlight-1 aliased to
> each other.

That'd be OK.

> So you are steering the discussion exactly to the opposite extreme.
> What is your motivation here.  Where do you think jit named-faces could
> be useful, apart from highlighting case.

I'm not talking about face names.  I'm only talking about the string the
user would type in.  They'd turn into (:background "yellow") style
values to use for the `face' property (yup, you don't have to use named
faces there).


        Stefan

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

[Jambunathan K]

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

> How 'bout designing a concise "face description" format, so that instead
> of choosing "hi-yellow", the user can choose (say) "b:yellow",
> "f:blue", or "s:bold".  This would give access to "any color", and in
> order not to overwhelm the user, the completion would default to only
> completing among a predefined set (corresponding to the current
> predefined faces)?

I was trying to refine this line of thought.  It leads to facemenu.el,
specifically `facemenu-set-foreground' and `facemenu-set-background'.

Stay with me, as I explain.

----------------------------------------------------------------

Currently highlighting works as follows:

    1. Choose a regexp via minibuffer
    2. Choose a face via minibuffer
    3. Decorate the buffer via font lock keywords.

Let me call this model, "Tell and Do".  Highlighting is explicitly
"Told" via minibuffer.
    
----------------------------------------------------------------

Let me propose a new scheme which will work as below.

1. Mark a word or a symbol under point
        C-M-@

2. Decorate region which is but a instance to be highlighted

        M-x facemenu-set-foreground RET
        M-x facemenu-set-background RET
        M-x facemenu-set-bold RET
        & co.

3. Highlight
        M-s h r or C-x w h.

   Face properties used for highlighting will be use results determined
   by 2.

This model is "Show and Tell".  Face properties of highlighting are
"Shown" right in the buffer that is edited (as opposed to a minibuffer
prompt) and highlighting library infers the face properties based on
text at point.

----------------------------------------------------------------

There is a functional parity between `hi-lock-face-defaults' and
`facemenu-listed-faces'.

----------------------------------------------------------------

Problem statement/Possible way ahead
====================================

Of course facemenu.el, "works" only for certain modes.

More specifically it works only for those modes that defines a
`facemenu-enable-faces-p'.  The notion of persistence of face properties
(as in serializing/encoding face properties in to the edited text) is
"in built" in to facemenu.el.

I have more ideas on how facemenu.el can play nicely with other
libraries.  I will dump my thoughts in a separate bug report.

----------------------------------------------------------------

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

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

> I have more ideas on how facemenu.el can play nicely with other
> libraries.  I will dump my thoughts in a separate bug report.

See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14157

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

[David Koppelman]

Jambunathan K <kjambunathan@gmail.com> writes:

> Let me propose a new scheme which will work as below.
  ...

I'm not sure I understand the point. I'm pretty sure you are not
suggesting that the hi-lock commands be replaced by something like
highlight-other-matches to be used after a sequence of facemenu
commands. That would be too cumbersome.

Stefan's concise face description format sounds reasonable, especially
since it could be used in other modes maybe through a function like
(concise-face-get-face STR) that creates a new face or returns an
existing one. That would avoid loading hi-lock with unneeded
complexity.


I think there are more useful improvements than face handling that can
be made to hi-lock. For example, a way to save highlighting patterns in
a separate file.



Jambunathan K <kjambunathan@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> How 'bout designing a concise "face description" format, so that instead
>> of choosing "hi-yellow", the user can choose (say) "b:yellow",
>> "f:blue", or "s:bold".  This would give access to "any color", and in
>> order not to overwhelm the user, the completion would default to only
>> completing among a predefined set (corresponding to the current
>> predefined faces)?
>
> I was trying to refine this line of thought.  It leads to facemenu.el,
> specifically `facemenu-set-foreground' and `facemenu-set-background'.
>
> Stay with me, as I explain.
>
> ----------------------------------------------------------------
>
> Currently highlighting works as follows:
>
>     1. Choose a regexp via minibuffer
>     2. Choose a face via minibuffer
>     3. Decorate the buffer via font lock keywords.
>
> Let me call this model, "Tell and Do".  Highlighting is explicitly
> "Told" via minibuffer.
>     
> ----------------------------------------------------------------
>
> Let me propose a new scheme which will work as below.
>
> 1. Mark a word or a symbol under point
>         C-M-@
>
> 2. Decorate region which is but a instance to be highlighted
>
>         M-x facemenu-set-foreground RET
>         M-x facemenu-set-background RET
>         M-x facemenu-set-bold RET
>         & co.
>
> 3. Highlight
>         M-s h r or C-x w h.
>
>    Face properties used for highlighting will be use results determined
>    by 2.
>
> This model is "Show and Tell".  Face properties of highlighting are
> "Shown" right in the buffer that is edited (as opposed to a minibuffer
> prompt) and highlighting library infers the face properties based on
> text at point.
>
> ----------------------------------------------------------------
>
> There is a functional parity between `hi-lock-face-defaults' and
> `facemenu-listed-faces'.
>
> ----------------------------------------------------------------
>
> Problem statement/Possible way ahead
> ====================================
>
> Of course facemenu.el, "works" only for certain modes.
>
> More specifically it works only for those modes that defines a
> `facemenu-enable-faces-p'.  The notion of persistence of face properties
> (as in serializing/encoding face properties in to the edited text) is
> "in built" in to facemenu.el.
>
> I have more ideas on how facemenu.el can play nicely with other
> libraries.  I will dump my thoughts in a separate bug report.
>
> ----------------------------------------------------------------

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

[Jambunathan K]

David Koppelman <koppel@ece.lsu.edu> writes:

> Stefan's concise face description format sounds reasonable

How exhaustive should this "concise" description be?  I think it might
suffice to just look at those face specifications which facemenu offers.

What could be the usecase for such a face description?

----------------------------------------------------------------

Search for "fg:" or "bg:" in facemenu.

What I meant is the sequence of commands

        M-o b, M-o f black, M-o b yellow

is indeed a mnemonic for creating "bold face, with black foreground and
yellow background".  There is no particular order in which they are
composed and they are primitives in their own way.

----------------------------------------------------------------

bug#13686: 24.3.50; Re-look hi-lock-face-defaults (aka Provide more "core" faces for highlighting)

[Jambunathan K]

OP here.  Closed.