bug#47574: 'match' face is too bright

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#47574: 'match' face is too bright

Eli Zaretskii
> From: Dmitry Gutov <[hidden email]>
> Date: Sat, 3 Apr 2021 02:42:43 +0300
>
> Split off from the discussion in bug#47012.
>
> I think the current "yellow1" is too bright and in-your-face.
>
> It handles its goal (having the matched substrings noticed) admirably,
> but perhaps too well, because we normally don't want to reach each
> match, but rather the contents of the line around it. So I think it's
> not productive putting so much visual attention on it.

If someone wants to see the lines without the match standing out, they
can customize list-matching-lines-face to nil.  So this use case is
already covered.

FTR, I do want to see the match itself, so this face does its job for
me very well.

> Juri suggested #ffff88, and it seems good to me. Both readable and
> noticeable, yet not too bright.
>
> My original suggestions were "lemon chiffon" (seems ideally subdued to
> me, but it would be a drastic change), "khaki1" or "light goldenrod".

If we change the face's colors, we should make sure the new colors
look well on both light and dark backgrounds.



Reply | Threaded
Open this post in threaded view
|

bug#47574: 'match' face is too bright

Dmitry Gutov
On 03.04.2021 09:39, Eli Zaretskii wrote:

>> From: Dmitry Gutov <[hidden email]>
>> Date: Sat, 3 Apr 2021 02:42:43 +0300
>>
>> Split off from the discussion in bug#47012.
>>
>> I think the current "yellow1" is too bright and in-your-face.
>>
>> It handles its goal (having the matched substrings noticed) admirably,
>> but perhaps too well, because we normally don't want to reach each
>> match, but rather the contents of the line around it. So I think it's
>> not productive putting so much visual attention on it.
>
> If someone wants to see the lines without the match standing out, they
> can customize list-matching-lines-face to nil.  So this use case is
> already covered.

I'm talking rather about the other uses of the 'match' face: the Grep
buffer, the Occur buffer, and the uses of the xref-match face (which
inherits from 'match' now) inside the Xref buffer (xref-find-references
or project-find-regexp).

My argument is that it's the dominant use case, so it's worth trying to
improve the default configuration.

> FTR, I do want to see the match itself, so this face does its job for
> me very well.

Sure, I do too. From my experience, though, it's visible enough with any
of the proposed colors. Even 'lemon chiffon', though I agree the result
is fairly subtle.

>> Juri suggested #ffff88, and it seems good to me. Both readable and
>> noticeable, yet not too bright.
>>
>> My original suggestions were "lemon chiffon" (seems ideally subdued to
>> me, but it would be a drastic change), "khaki1" or "light goldenrod".
>
> If we change the face's colors, we should make sure the new colors
> look well on both light and dark backgrounds.

My proposal is specifically for the light background (the min-colors 88
case), with the default theme as the baseline.

Looking at the dark background color (and trying it with a couple of
dark themes), I think it could use some toning down as well from
RoyalBlue3 to RoyalBlue4, but others who prefer dark backgrounds can
probably tell better.



Reply | Threaded
Open this post in threaded view
|

bug#47574: 'match' face is too bright

Stefan Kangas
In reply to this post by Eli Zaretskii
[Resending my reply as I accidentally sent it only to Eli.]

Eli Zaretskii <[hidden email]> writes:

>> Juri suggested #ffff88, and it seems good to me. Both readable and
>> noticeable, yet not too bright.

I don't see a very large difference between yellow and #ffff88, but I
guess it's slightly better than what we have now.

>> My original suggestions were "lemon chiffon" (seems ideally subdued to
>> me, but it would be a drastic change), "khaki1" or "light goldenrod".

FWIW, I think "lemon chiffon" is by far the best one.  It also fits
better with the rest of the default theme.

This is followed by "khaki1" or "light goldenrod", in that order.

I'm not against #ffff88 if that's what people want to see, but the
change is not large enough to make much of a difference here.

> If we change the face's colors, we should make sure the new colors
> look well on both light and dark backgrounds.

Yup.

I think "khaki3" stands out sufficiently well and goes well together
with "lemon chiffon", but there is obviously room for experimentation.



Reply | Threaded
Open this post in threaded view
|

bug#47574: 'match' face is too bright

Dmitry Gutov
On 14.04.2021 17:55, Stefan Kangas wrote:
> [Resending my reply as I accidentally sent it only to Eli.]
>
> Eli Zaretskii <[hidden email]> writes:
>
>>> Juri suggested #ffff88, and it seems good to me. Both readable and
>>> noticeable, yet not too bright.
>
> I don't see a very large difference between yellow and #ffff88, but I
> guess it's slightly better than what we have now.

What do people think about #ffffbb, then? It's the other color Juri
mentioned.

Stefan? Eli?

It's also relatively low-key like "lemon chiffon", but a bit more
noticeable. And it seems to fit the default theme very well.

>>> My original suggestions were "lemon chiffon" (seems ideally subdued to
>>> me, but it would be a drastic change), "khaki1" or "light goldenrod".
>
> FWIW, I think "lemon chiffon" is by far the best one.  It also fits
> better with the rest of the default theme.
>
> This is followed by "khaki1" or "light goldenrod", in that order.

I guess we'll fall back to "khaki1" if the more radical options are not
accepted.

> I'm not against #ffff88 if that's what people want to see, but the
> change is not large enough to make much of a difference here.
>
>> If we change the face's colors, we should make sure the new colors
>> look well on both light and dark backgrounds.
>
> Yup.
>
> I think "khaki3" stands out sufficiently well and goes well together
> with "lemon chiffon", but there is obviously room for experimentation.

If we're talking about dark background, it should be at least khaki4
(the text is hard to read otherwise), or the RoyalBlue4 I suggested as
the tweak for the current dark-bg color of this face.

Although the current RoyalBlue3 seems to have about the same level of
brightness as khaki4. So it's not out of the question to just leave the
current color there.

If we change the dark-bg color to khaki, I think we'd also need to
change the spec for ((class color) (min-colors 8) (background dark)),
and setting it to "yellow" is probably not a good idea.

Wish we had some dark-background users in this discussion.



Reply | Threaded
Open this post in threaded view
|

bug#47574: [External] : bug#47574: 'match' face is too bright

Drew Adams
> Wish we had some dark-background users in this discussion.

Why limit a discussion of changing some default
behavior to a bug thread?

(I don't care about the default value of this.
I just think it's not generally wise to limit
default-changes to bug threads.)
Reply | Threaded
Open this post in threaded view
|

bug#47574: [External] : bug#47574: 'match' face is too bright

Dmitry Gutov
On 15.04.2021 17:56, Drew Adams wrote:
> Why limit a discussion of changing some default
> behavior to a bug thread?

I'm using a bug report to be able to post a sane reference to the
discussion in the resulting commit message.

Please feel free to post to emacs-devel to notify anybody interested
that such discussion is taking place here.



Reply | Threaded
Open this post in threaded view
|

bug#47574: [External] : bug#47574: 'match' face is too bright

Drew Adams
> > > Wish we had some dark-background users
> > > in this discussion.
> >
> > Why limit a discussion of changing some
> > default behavior to a bug thread?
>
> I'm using a bug report to be able to post a sane
> reference to the discussion in the resulting commit message.

Nothing wrong with referring to a bug #/thread
in a commit msg -- after soliciting discussion,
and discussing, in emacs-devel.

The question was about _limiting_ discussion to
a bug thread.  And the answer is?

> Please feel free to post to emacs-devel to notify
> anybody interested that such discussion is taking place here.

I'll let you do that, if you think it's relevant.

Maybe you'd like to do that if and when the
discussion here comes to trying to decide
(1) whether to change the default for this face
and, if so, (2) what to change it to.

I think it makes sense to discuss default changes
in emacs-devel (and not just to notify that list
that there's a discussion here about a possible
default change).  Just one opinion.