Find out what is setting color in minibufer

Find out what is setting color in minibufer

[Fernando Basso]

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

I have been using Emacs from the terminal recently. It works fine and it
helps me with my tmux workflow. However, when I am using Geiser mode the
minibuffer shows documentation hints in a shade of blue that makes it hard
to read. I don't know if it is Geiser or something else that is setting
that color. It seems the color remains even if I load a different theme.
Also, that color is not set in my Xresources file.

How should I proceed to find out what is setting that color? Emacs 25 on
arch linux.

I am attaching a screenshot in the hope that it will help.

Thanks in advance.

[-- Attachment #2: geiser-docs-color.png --]
[-- Type: image/png, Size: 40239 bytes --]

Re: Find out what is setting color in minibufer

[Alex Kost]

Fernando Basso (2016-11-25 20:45 -0200) wrote:

> I have been using Emacs from the terminal recently. It works fine and it
> helps me with my tmux workflow. However, when I am using Geiser mode the
> minibuffer shows documentation hints in a shade of blue that makes it hard
> to read. I don't know if it is Geiser or something else that is setting
> that color. It seems the color remains even if I load a different theme.
> Also, that color is not set in my Xresources file.
>
> How should I proceed to find out what is setting that color? Emacs 25 on
> arch linux.
>
> I am attaching a screenshot in the hope that it will help.

This is 'geiser-font-lock-autodoc-identifier' face which should have the
same look as 'font-lock-function-name-face' by default.  So it's either
your custom theme or your customization that you should blame.

If you want to change this face, you can do it with "M-x customize-face
geiser-font-lock-autodoc-identifier".  Also check
'font-lock-function-name-face': if it is the same then better change it
instead as it is one of the "core" faces; or even change your theme :-)

-- 
Alex

Re: Find out what is setting color in minibufer

[Alex Kost]

Alex Kost (2016-11-26 22:02 +0300) wrote:

> Fernando Basso (2016-11-25 20:45 -0200) wrote:
>
>> I have been using Emacs from the terminal recently. It works fine and it
>> helps me with my tmux workflow. However, when I am using Geiser mode the
>> minibuffer shows documentation hints in a shade of blue that makes it hard
>> to read. I don't know if it is Geiser or something else that is setting
>> that color. It seems the color remains even if I load a different theme.
>> Also, that color is not set in my Xresources file.
>>
>> How should I proceed to find out what is setting that color? Emacs 25 on
>> arch linux.
>>
>> I am attaching a screenshot in the hope that it will help.
>
> This is 'geiser-font-lock-autodoc-identifier' face which should have the
> same look as 'font-lock-function-name-face' by default.  So it's either
> your custom theme or your customization that you should blame.

Sorry, I think I was wrong.  It's likely not the fault of your theme.
The problem is that this face *does not inherit* from
'font-lock-function-name-face' but it uses its default specification
instead:

  (defface geiser-font-lock-autodoc-identifier
    (face-default-spec 'font-lock-function-name-face)
    "Face for highlighting procedure name in autodoc messages."
    :group 'geiser-autodoc
    :group 'geiser-faces)

(this is actually done via 'geiser-custom--defface' macro but it doesn't
matter:
<https://github.com/jaor/geiser/blob/master/elisp/geiser-autodoc.el#L32-L34>)

So if your theme changes 'font-lock-function-name-face', that autodoc
face will still use the default face specification (which apparently
doesn't look good in a terminal).

After all, I would say it's a Geiser problem: faces should inherit from
other (particuarly 'font-lock') faces and should not copy their specs as
it is done in Geiser faces.

-- 
Alex

face inheritance [was: Find out what is setting color in minibufer]

[Drew Adams]

> After all, I would say it's a Geiser problem: faces should 
> inherit from other (particuarly 'font-lock') faces and
> should not copy their specs as it is done in Geiser faces.

I have nothing to say about the particular question raised
in this thread.  But I have a comment about the last, "faces 
should" statement (which is a _general guideline_ and, like
my comment, not a judgment about this particular Geiser
situation):

I could not disgree more - both with the general claim and
with the "particularly 'font-lock'" part.

Code should NOT create faces that inherit from other faces,
unless the intention is precisely to create such a default
dependence (only by default, since faces can always be
customized).

In particular, faces should generally NOT inherit from
font-lock faces, unless you really want/need such a
dependence.

If you don't believe me, just ask yourself what happens
when a user customizes your new face: the dependence is
gone. If you are relying on it as more than just a
convenience for defaulting attribute values, then you
are out of luck.

And if for some reason your code really needs such a
dependency to remain, so that there is no way to customize
the new face, and the only change a user should make is to 
customize the inherited (e.g. font-lock) face, then your
code should just use that face directly and not define a
new face that inherits from it.

The easiest way to see what the right approach is for your
code is to play user and customize the face.  If the result
is broken behavior then you should not have defined the face
in the first place.

If you define a face, then users are, and should be, able to
change it.  If your code tries to highlight something with
that face, and if that something is also being highlighted
by some other code, in particular by font-locking, then that
is a conflict that you need to take care of.

It should be quite possible for a user to customize certain
faces whose effect is NOT changed by imposing or changing a
theme.  Other faces, on the other hand, are expected to be
changed by a given theme.  A theme typically does not affect
all faces.  It all depends on what you want for your code,
including what you want its users to be able to do.

IMHO, there is far too much code that defines faces using
inheritance (and this includes some in the distributed Emacs
code).  That can be useful, but its strength is also its
weakness: Any change to the inherited face affects the new
face - unless the user customizes the latter.

Faces are defined for a given initial context.  When they
are reused for a completely different context the result
is something else again.  If the contexts are similar enough
then the reuse might still work; otherwise, it might not.

For example, a particular color for a font-lock face such
as `font-lock-lock-keyword-face', might make perfect sense
for typical font-lock, programming contexts.  But it might
not make sense for some other context - even if it might
seem to its author to look good in the default context.

Font-lock faces, in particular, work together.  If a user
changes one or two to fit her context, she may also change
some of the others.

The reflection of such a change in the context of a
library that defines a face that inherits from a font-lock
face will not necessarily be TRT.  And that can force a
user to customize the face that inherits.

When you use a face for your library, ask yourself how
similar its use/behavior is to that of a face defined for
another context:

* If it is very, VERY similar, then you might want to just
  use that existing face (no new face).

* If it is very similar, but you want users to be able to
  change it independently, then you might want to use a
  new face that inherits from the existing face.

* If it is not very similar then you might want to define
  it without using inheritance.

In particular, do NOT inherit from a face just because you
think its default attributes (e.g. colors) are appropriate
as defaults for your context.  If that is the ONLY reason
you are considering inheritance then just define a new
face with the same attribute values - no inheritance.

The goal should be to do something appropriate for your
specific context that is also the most helpful for users.
The goal should NOT be to minimize the number of faces.

Re: Find out what is setting color in minibufer

[Alex Kost]

Fernando Basso (2016-11-26 18:27 -0200) wrote:

> Thanks for helping me out. So, if I understand it, it means I would
> have to change Geiser somewhere where it sets the color for
> 'geiser-autodoc'?

No, as I told, you can change this face with "M-x customize-face
geiser-font-lock-autodoc-identifier".

Please keep the mailing list Cc-ed.

-- 
Alex