faces `compilation-info' and `compilation-line-number'

faces `compilation-info' and `compilation-line-number'

[Drew Adams]

Until recently, these faces were defined as follows (using inheritance from
`font-lock-variable-name-face'):

compilation-info:        Green3 foreground, and bold
         (Green1 if dark background; Green if min colors)
compilation-line-number: font-lock-variable-name-face

Now they are defined this way (inheritance):

compilation-info:        font-lock-type-face
compilation-line-number: font-lock-keyword-face

I suggest they be defined this way instead (inheritance):

compilation-info:        font-lock-keyword-face
compilation-line-number: font-lock-variable-name-face

I think that is more readable.  In compilation and grep buffers readability of
file names is more important than readability of line numbers.  And
`font-lock-keyword-face' is generally used more than `font-lock-type-face', so
the former tends to be more legible than the latter.  That's the case even
taking user customization into account: users tend to make sure that the most
commonly used faces fit their needs.

This would also keep the same face for line numbers that we had prior to the
recent change (going at least as far back as Emacs 20).  (True, keeping the same
line-number face is not too important.)  And `font-lock-variable-name-face' is
also a commonly used face, so it is likely to be more legible for more users
than is the more seldom seen `font-lock-type-face'.

Following this suggestion the only change from the past would thus be for face
`compilation-info' (highlighting file names): it would inherit from
`font-lock-keyword-face' instead of using a Green3 + bold foreground.  (FWIW,
prior to Emacs 22, `font-lock-warning-face' was used for the file names.)

I imagine that the recent change was made in order to inherit, but also to keep
face `compilation-info' as some shade of green (`ForestGreen' is the default
foreground for `font-lock-type-face').

Keeping the default foreground green is less important than readability, IMO.
Because of its widespread use, users are more likely to customize
`font-lock-keyword-face', so it is more likely that it is more readable than
`font-lock-type-face'.  (Likewise, `font-lock-variable-name-face' vs
`font-lock-type-face'.)

Example: I use a Blue3 foreground for `font-lock-keyword-face', and I don't
customize `font-lock-type-face' (or `font-lock-variable-name-face').  Blue3 is
much more readable for file names than is ForestGreen.  (I use a light
background.)

Re: faces `compilation-info' and `compilation-line-number'

[Stefan Monnier]

> Now they are defined this way (inheritance):

> compilation-info:        font-lock-type-face
> compilation-line-number: font-lock-keyword-face

> I suggest they be defined this way instead (inheritance):

> compilation-info:        font-lock-keyword-face
> compilation-line-number: font-lock-variable-name-face

At first sight, I'd tend to agree, just on the basis of minimizing
change.  But I think neither makes any sense, really.  We should instead
introduce new faces (one for errors, one for warnings, one for
information), and then inherit from those (and make
font-lock-warning-face inherit from `error' for hysterical raisins).


        Stefan

Re: faces `compilation-info' and `compilation-line-number'

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

On Wed, Feb 16, 2011 at 8:07 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > Now they are defined this way (inheritance):
>
> > compilation-info:        font-lock-type-face
> > compilation-line-number: font-lock-keyword-face
>
> > I suggest they be defined this way instead (inheritance):
>
> > compilation-info:        font-lock-keyword-face
> > compilation-line-number: font-lock-variable-name-face
>
> At first sight, I'd tend to agree, just on the basis of minimizing
> change.  But I think neither makes any sense, really.  We should instead
> introduce new faces (one for errors, one for warnings, one for
> information), and then inherit from those (and make
> font-lock-warning-face inherit from `error' for hysterical raisins).
>
>
>        Stefan
>
> While I think we need to be wary of creating too many faces, the addition
of base faces for warnings, errors and information would seem like a good
idea and a justified addition.

Tim

[-- Attachment #2: Type: text/html, Size: 1356 bytes --]

Re: faces `compilation-info' and `compilation-line-number'

[John Yates]

 On Thu, Feb 3, 2011 in "Eliminating a couple of independent face
definitions"  Stephen J. Turnbull wrote:

> The basic problem is that faces are not colors.  Faces are not fonts.
> (Where have I heard this before? ;-)  A face is a semantic component,
> intended to express meaning.  Common meanings should have a common
> expression.

Somewhat incoherently I attempted to introduce another perspective.
On reflection my mistake seems to have been to take issue with
Stephen's definition of a face.  What I had wanted to show is that
users often customize faces for reasons other than semantic
consistency.  That they use faces as a poor man's substitute for the
theming capability present in many GUI frameworks.

This new thread hinges not on aligning semantics but on which elements
in a given setting merit more or less visual emphasis.  That was
exactly the perspective I tried to capture in my earlier posting.

I have come to think that what emacs lacks is a palette framework.  I
imagine the palette framework as a partial order of degrees of
emphasis.  For lack of a better term I will call the members of this
partial order roles.  This ordering relationship would be captured in
the role names.  Thus we might have

garish
strident-2
strident-1a, strident-1b
emphasis-2
emphasis-1a, emphasis-1c, emphasis-1c
normal
deemphasis-1a , deemphasis-1b
deemphasis-2

(High lighting probably belongs in this list by I am not sure exactly where.)

Emacs would provide style guidance for the palette roles.  E.g. garish
applies to a limited span (a word or token, not the better part of a
line); strident-1a/b are appropriate for entire lines.

An actual palette is realized by associating with each role:
- a basic foreground/background color pair
- a font modification rule. Examples: base, bold else base, italic
else underline else base

Notice that a palette is less than a face because it is not associated
with a font or font family.  Applying a palette to a font family would
result in a basic set of faces (e.g. palette-garish,
palette-strident-2, palette-normal, etc).  These faces could then form
the basis for a set of derived faces that would introduce a base set
of semantic notions.

/john

Re: faces `compilation-info' and `compilation-line-number'

[Miles Bader]

John Yates <john@yates-sheets.org> writes:
> Notice that a palette is less than a face because it is not associated
> with a font or font family.

Er, but a face isn't necessarily associated with a font/font-family
either (and indeed, usually isn't)...

-Miles

-- 
Zeal, n. A certain nervous disorder afflicting the young and inexperienced.