GNU bug report logs -
#16969
Isearch: lazy-highlight face sometimes has foreground and background the same colour.
Previous Next
Reported by: Alan Mackenzie <acm <at> muc.de>
Date: Sat, 8 Mar 2014 18:40:02 UTC
Severity: minor
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16969 in the body.
You can then email your comments to 16969 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16969
; Package
emacs
.
(Sat, 08 Mar 2014 18:40:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Alan Mackenzie <acm <at> muc.de>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 08 Mar 2014 18:40:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi, Emacs.
In isearch.el, the face `lazy-highlight' is defined with only a
:background colour, e.g. turquoise3. On a Linux tty, this is cyan.
When the text which has a lazy match itself has a cyan foreground
colour, the lazy highlighting leaves the cyan text on a cyan background
invisible. This happens, for example, on the Linux tty when searching
through an Info menu. This is surely a bug.
An effective solution would be to give the `lazy-highlight' face a
foreground colour, e.g. black.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16969
; Package
emacs
.
(Sat, 08 Mar 2014 22:08:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 16969 <at> debbugs.gnu.org (full text, mbox):
> An effective solution would be to give the `lazy-highlight' face a
> foreground colour, e.g. black.
It's useful to keep the foreground color to help seeing the context
especially when a match is highlighted on a font-look foreground.
But the problem needs to be fixed anyway. So maybe we could add the
face attribute :distant-foreground to the `lazy-highlight' face
that could be applied only when the background color is near to the
foreground color like a cyan foreground on a cyan background.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16969
; Package
emacs
.
(Sat, 08 Mar 2014 23:05:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 16969 <at> debbugs.gnu.org (full text, mbox):
Hi, Juri.
On Sat, Mar 08, 2014 at 11:55:45PM +0200, Juri Linkov wrote:
> > An effective solution would be to give the `lazy-highlight' face a
> > foreground colour, e.g. black.
> It's useful to keep the foreground color to help seeing the context
> especially when a match is highlighted on a font-look foreground.
Yes.
> But the problem needs to be fixed anyway. So maybe we could add the
> face attribute :distant-foreground to the `lazy-highlight' face
> that could be applied only when the background color is near to the
> foreground color like a cyan foreground on a cyan background.
I don't know what ":distant-foreground" means. It doesn't seem to be in
the Elisp manual.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16969
; Package
emacs
.
(Sun, 09 Mar 2014 00:46:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 16969 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 03/08/2014 01:55 PM, Juri Linkov wrote:
>> An effective solution would be to give the `lazy-highlight' face a
>> foreground colour, e.g. black.
>
> It's useful to keep the foreground color to help seeing the context
> especially when a match is highlighted on a font-look foreground.
>
> But the problem needs to be fixed anyway. So maybe we could add the
> face attribute :distant-foreground to the `lazy-highlight' face
> that could be applied only when the background color is near to the
> foreground color like a cyan foreground on a cyan background
And what? Are we going to apply distant-foreground to everything and
hope that the color we choose is legible in whatever theme the user has?
We really need automatic contrast adjustment, not one-off fixes.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16969
; Package
emacs
.
(Sun, 09 Mar 2014 09:38:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 16969 <at> debbugs.gnu.org (full text, mbox):
Hi.
Alan Mackenzie skrev 2014-03-09 00:01:
> Hi, Juri.
>
> On Sat, Mar 08, 2014 at 11:55:45PM +0200, Juri Linkov wrote:
>>> An effective solution would be to give the `lazy-highlight' face a
>>> foreground colour, e.g. black.
>
>> It's useful to keep the foreground color to help seeing the context
>> especially when a match is highlighted on a font-look foreground.
>
> Yes.
>
>> But the problem needs to be fixed anyway. So maybe we could add the
>> face attribute :distant-foreground to the `lazy-highlight' face
>> that could be applied only when the background color is near to the
>> foreground color like a cyan foreground on a cyan background.
>
> I don't know what ":distant-foreground" means. It doesn't seem to be in
> the Elisp manual.
You can't have looked very hard.
Faces => Face attributes:
`:distant-foreground'
Alternative foreground color, a string. This is like `:foreground'
but the color is only used as a foreground when the background
color is near to the foreground that would have been used. This
is useful for example when marking text (i.e. the region face).
If the text has a foreground that is visible with the region face,
that foreground is used. If the foreground is near the region
face background, `:distant-foreground' is used instead so the text
is readable.
Jan D.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16969
; Package
emacs
.
(Sun, 09 Mar 2014 13:30:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 16969 <at> debbugs.gnu.org (full text, mbox):
On Sun, Mar 09, 2014 at 10:37:48AM +0100, Jan Djärv wrote:
> Hi.
> Alan Mackenzie skrev 2014-03-09 00:01:
> > I don't know what ":distant-foreground" means. It doesn't seem to be in
> > the Elisp manual.
> You can't have looked very hard.
:-). It was late at night. I had the release version of the Elisp
manual open, not the trunk version.
> Faces => Face attributes:
> `:distant-foreground'
> Alternative foreground color, a string. This is like `:foreground'
> but the color is only used as a foreground when the background
> color is near to the foreground that would have been used. This
> is useful for example when marking text (i.e. the region face).
> If the text has a foreground that is visible with the region face,
> that foreground is used. If the foreground is near the region
> face background, `:distant-foreground' is used instead so the text
> is readable.
Thanks!
> Jan D.
--
Alan Mackenzie (Nuremberg, Germany).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16969
; Package
emacs
.
(Sun, 09 Mar 2014 21:52:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 16969 <at> debbugs.gnu.org (full text, mbox):
>> But the problem needs to be fixed anyway. So maybe we could add the
>> face attribute :distant-foreground to the `lazy-highlight' face
>> that could be applied only when the background color is near to the
>> foreground color like a cyan foreground on a cyan background
>
> And what? Are we going to apply distant-foreground to everything and
> hope that the color we choose is legible in whatever theme the user has?
We need to guarantee that default faces don't produce illegible
combinations of foreground and background colors. This can be achieved
by using :distant-foreground on the default face definition.
A user redefining the face can also manually adjust :distant-foreground
to use another color if the user doesn't like the default color
used when the distance is more than the threshold.
> We really need automatic contrast adjustment, not one-off fixes.
Automatic contrast adjustment is useful too when the user has no preference
for a color to use instead of an illegible color and want to adjust all
such colors automatically. There is a request in bug#16974 for this feature.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16969
; Package
emacs
.
(Sun, 09 Mar 2014 22:22:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 16969 <at> debbugs.gnu.org (full text, mbox):
> We need to guarantee that default faces don't produce
> illegible combinations of foreground and background colors.
Yes, that is the _only_ *need* here. It is the need raised
by the bug.
And the simplest and most foolproof way to fulfill that need and
fix the bug is to simply give face `lazy-highlight', by default,
a black/white foreground for a light/dark background mode.
Just as we do already for face `isearch', and just as we have
always done. That should have been done for `lazy-highlight'
long ago. End of story.
Any user who wants to fiddle with the new "feature" that lets
other highlighting show through and tries to adjust colors
automatically can always customize these search-hit faces to get
that new effect. There is no reason to impose this gimmick on
Emacs users now by _default_.
Today's flashy new feature is too often tomorrow's out-of-fashion
annoyance. Just stick with what is simple and has always worked
well. If, after a few years, we find that _most users choose_ to
customize to get the new effect, we can then turn it on by default.
There is no reason to jump to that now.
It amazes me that it took so long and was such a bloody battle to
get something like `transient-mark-mode' turned on by default,
even though users commonly customized Emacs for decades to turn it
on, and yet you are ready to willy nilly change longstanding
default behavior such as this before the new behavior has even
been offered as a possibility for users to _choose_. It hasn't
even been released yet, and you already want to make it the default.
First things first: turn on `delete-selection-mode' by default,
why dontcha? And offer this new highlighting style as an
_option_ for now: opt in, not opt out, for the new.
Consider making it the default behavior only later, after you have
had a chance to see how many users actually choose it. Don't get
carried away by your enthusiasm for your shiny new object.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16969
; Package
emacs
.
(Mon, 10 Mar 2014 03:02:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 16969 <at> debbugs.gnu.org (full text, mbox):
> And what? Are we going to apply distant-foreground to everything and
> hope that the color we choose is legible in whatever theme the user has?
For now, yes.
> We really need automatic contrast adjustment, not one-off fixes.
Not sure about "really", but I agree it's a desirable feature. But it
won't be in 24.4.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16969
; Package
emacs
.
(Sat, 05 Feb 2022 22:47:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 16969 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> jurta.org> writes:
> But the problem needs to be fixed anyway. So maybe we could add the
> face attribute :distant-foreground to the `lazy-highlight' face
> that could be applied only when the background color is near to the
> foreground color like a cyan foreground on a cyan background.
I've now done this in Emacs 29.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
16969 <at> debbugs.gnu.org and Alan Mackenzie <acm <at> muc.de>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 05 Feb 2022 22:47:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 06 Mar 2022 12:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 108 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.