bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Eli Zaretskii]

I think the default background color of this face is not the best
possible one: it's too close to light background people could use,
even to the default one.  It makes this new face almost useless.

I suggest to re-think the default.

In GNU Emacs 28.0.50 (build 1077, i686-pc-mingw32)
 of 2021-03-09 built on HOME-C4E4A596F7
Repository revision: 29458ec7d2843baa725f9b613d0e935df3a61301
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int --with-modules
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM
ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: ELisp/l

Minor modes in effect:
  bug-reference-prog-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search seq byte-opt
gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils misearch multi-isearch vc-git
diff-mode easy-mmode vc-dispatcher bug-reference time-date subr-x
cl-loaddefs cl-lib iso-transl tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win
w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads w32notify
w32 lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 65328 10799)
 (symbols 48 8380 1)
 (strings 16 24975 2430)
 (string-bytes 1 716004)
 (vectors 16 14535)
 (vector-slots 8 197481 15388)
 (floats 8 35 82)
 (intervals 40 755 141)
 (buffers 888 14))

bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Juri Linkov]

> I think the default background color of this face is not the best
> possible one: it's too close to light background people could use,
> even to the default one.  It makes this new face almost useless.
>
> I suggest to re-think the default.

emacs.stackexchange.com uses #e4e6e8 that corresponds to grey90,
so it's the gold standard.

bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 47047@debbugs.gnu.org
> Date: Wed, 10 Mar 2021 21:59:50 +0200
> 
> > I think the default background color of this face is not the best
> > possible one: it's too close to light background people could use,
> > even to the default one.  It makes this new face almost useless.
> >
> > I suggest to re-think the default.
> 
> emacs.stackexchange.com uses #e4e6e8 that corresponds to grey90,
> so it's the gold standard.

You mean use grey90 for the background of the help-key-binding face?
That's tough on me, since my default background color is grey86.  Oh
well...

bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juri Linkov <juri@linkov.net>
>> Cc: 47047@debbugs.gnu.org
>> Date: Wed, 10 Mar 2021 21:59:50 +0200
>>
>> > I think the default background color of this face is not the best
>> > possible one: it's too close to light background people could use,
>> > even to the default one.  It makes this new face almost useless.
>> >
>> > I suggest to re-think the default.
>>
>> emacs.stackexchange.com uses #e4e6e8 that corresponds to grey90,
>> so it's the gold standard.
>
> You mean use grey90 for the background of the help-key-binding face?
> That's tough on me, since my default background color is grey86.  Oh
> well...

It is of course impossible to find a default background colour that will
work with any colour.  The default was designed to work well with our
default white background.

bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Stefan Kangas]

Stefan Kangas <stefan@marxist.se> writes:

> It is of course impossible to find a default background colour that will
> work with any colour.  The default was designed to work well with our
> default white background.

I tested with all our bundled themes, and the only theme in which the
default looked out of place to me was wombat.el and light-blue-theme.el.

I have updated wombat.el with a new face definition that seems more in
line with the rest of that theme.  If anyone wants to tweak it even
further, please feel free.

Unfortunately, I don't understand what style light-blue-theme.el is
trying to achieve, so I left it alone.  Perhaps Drew will have some idea
what, if anything, should be done in that case.

bug#47047: [External] : Re: bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Drew Adams]

> Unfortunately, I don't understand what style light-blue-theme.el is
> trying to achieve, so I left it alone.  Perhaps Drew will have some idea
> what, if anything, should be done in that case.


Oooh.  "Trying to achieve."  Touché.

My own setup is similar in some ways.  The background
is light but not super-light (supposedly good for
avoiding eye strain).  It allows use of some face
foregrounds that are themselves not so dark.  It also
allows for dark face foregrounds.

You're free to delete light-blue-theme, if you like.
I don't use it, myself, and I won't miss it.

bug#47047: [External] : Re: bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Stefan Kangas]

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

>> Unfortunately, I don't understand what style light-blue-theme.el is
>> trying to achieve, so I left it alone.  Perhaps Drew will have some idea
>> what, if anything, should be done in that case.
>
> Oooh.  "Trying to achieve."  Touché.

I'm sorry if my way of expressing myself made it seem like I'm trying to
score points.  What I was trying to say is that I don't understand the
design goals of that theme, which means that any attempt on my end to
modify it is unlikely to produce good results.

bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Stefan Kangas]

tags 47047 fixed
close 47047 28.1
thanks

Stefan Kangas <stefan@marxist.se> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> It is of course impossible to find a default background colour that will
>> work with any colour.  The default was designed to work well with our
>> default white background.
>
> I tested with all our bundled themes, and the only theme in which the
> default looked out of place to me was wombat.el and light-blue-theme.el.
>
> I have updated wombat.el with a new face definition that seems more in
> line with the rest of that theme.  If anyone wants to tweak it even
> further, please feel free.
>
> Unfortunately, I don't understand what style light-blue-theme.el is
> trying to achieve, so I left it alone.  Perhaps Drew will have some idea
> what, if anything, should be done in that case.

No further comments within 6 months, so I'll assume the fixes I
installed at the time were sufficient.  I'm therefore closing this bug
report.

bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Stefan Kangas]

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

> You're free to delete light-blue-theme, if you like.
> I don't use it, myself, and I won't miss it.

Any other opinions about this part?

I'm leaning towards just deleting it given the above.

bug#47047: [External] : Re: bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Drew Adams]

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

> > You're free to delete light-blue-theme, if you like.
> > I don't use it, myself, and I won't miss it.
> 
> Any other opinions about this part?
> 
> I'm leaning towards just deleting it given the above.

Lean away.  However, I don't see the point
of deleting a theme because you find that
the default appearance of a face you defined
looks, according to you, "out of place" with
that theme.

The bug of this thread is that the default
background of a (new) face is suboptimal.  Is
there also some bug with the light-blue-theme?

You say that you think the new background you
chose for that new face looks out of place
with that theme.  Maybe file a bug report for
that?

What's the relation between the background you
chose to use by default and the definition of
_any_ theme?  Tail wagging dog?  I'm pretty
sure that, for any theme, you can find a color
that you'll think looks out of place.

Emacs 28 isn't even released yet.  You add a
face and then want to purge stuff that you
find "looks out of place" with your new face?

I won't try to stop you.  But I find such a
purge a bit "out of place".

FWIW, I looked at a face with background
"gray90", which from the bug thread I gather
is the default you chose.

(defface foo '((t (:background "gray90")))
  :group 'convenience)

I looked at it in my setup (which is about
the same as `light-blue-theme'), with
`list-faces-display'.  Seems to show up OK.
(See attached screenshot.)  Just how does
it look "out of place" to you?

If the point is about legibility/accessibility
then what counts is the value contrast between
foreground and background (nothing else really
counts).  Assuming your face doesn't change the
foreground, the legibility of the face stands
on its own: the value difference between its
foreground (black?) and its background, gray90.

As for the face itself (its background)
standing out against a general background that
has a similar color value: yes, that hinders
accessibility.  Someone with difficulty seeing
low value-contrast differences likely wouldn't
choose that theme anyway, or s?he might want to
customize some faces (including that new face).

An advantage of a pale (but not close to white)
background is the ability to easily see a range
of foreground colors, including very light and
very dark, but also mid-range (foregrounds and
backgrounds) if the hue is quite different.  As
with any theme or color scheme (and any face,
including this new one), it's optional and
configurable.

[-- Attachment #2: throw-gray90-bg.png --]
[-- Type: image/png, Size: 319570 bytes --]

bug#47047: [External] : Re: bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Stefan Kangas]

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

>> > You're free to delete light-blue-theme, if you like.
>> > I don't use it, myself, and I won't miss it.
>>
>> Any other opinions about this part?
>>
>> I'm leaning towards just deleting it given the above.
>
> Lean away.  However, I don't see the point
> of deleting a theme because you find that
> the default appearance of a face you defined
> looks, according to you, "out of place" with
> that theme.

You said above that you won't miss it, didn't you?  Maybe I
misunderstood you.

If that's not the case, there is nothing further to do here.

bug#47047: [External] : Re: bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Drew Adams]

> You said above that you won't miss it, didn't you?  Maybe I
> misunderstood you.

Yes, I did.  I won't miss it.  I don't see the
point of removing it, however.  And I don't see
that you've given a good reason for doing that.

> If that's not the case, there is nothing further to do here.

That's one way of looking at it, I guess.

bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> You're free to delete light-blue-theme, if you like.
>> I don't use it, myself, and I won't miss it.
>
> Any other opinions about this part?
>
> I'm leaning towards just deleting it given the above.

Do we have some mechanism to deprecate a theme?  If it's just deleted,
will that lead to breakage if a user has selected the theme?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Do we have some mechanism to deprecate a theme?  If it's just deleted,
> will that lead to breakage if a user has selected the theme?

No idea, but it's a very good point.  We have more than one theme that
is buggy, has low coverage and/or is not maintained, so maybe this is
something we should think about.

Perhaps it would be fine with something ad-hoc like dropping an lwarn at
the top level of the file, if we would want to do something like this.

bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Perhaps it would be fine with something ad-hoc like dropping an lwarn at
> the top level of the file, if we would want to do something like this.

The themes are loaded via `load-theme', aren't they?  (I don't really
know much about how themes work internally.)  If so, it looks pretty
trivial to make that function check whether there's the theme symbol has
been made obsolete, and then output a warning...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The themes are loaded via `load-theme', aren't they?  (I don't really
> know much about how themes work internally.)  If so, it looks pretty
> trivial to make that function check whether there's the theme symbol has
> been made obsolete, and then output a warning...

Sounds reasonable.

bug#47047: [External] : Re: bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Drew Adams]

> Do we have some mechanism to deprecate a theme?  If it's just deleted,
> will that lead to breakage if a user has selected the theme?

Do we have some reason to deprecate this theme,
beyond someone finding that a new face "looks
out of place" when that theme is used?

It's always good to see an actual reason.

bug#47047: [External] : Re: bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Stefan Kangas]

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

>> Do we have some mechanism to deprecate a theme?  If it's just deleted,
>> will that lead to breakage if a user has selected the theme?
>
> Do we have some reason to deprecate this theme,
> beyond someone finding that a new face "looks
> out of place" when that theme is used?
>
> It's always good to see an actual reason.

FWIW, I would personally object to removing a theme on non-technical
grounds.

In any case, you objected, and AFAIU you are still the maintainer so in
that sense there is nothing to discuss here.  The theme is staying, at
least until our maintainers say otherwise (the same as for all things).

As for reasons to remove a theme, I wrote before:

    "We have more than one theme that is buggy, has low coverage and/or
    is not maintained, so maybe this is something we should think
    about."

I can't say if it is buggy or not, but I think it has low coverage, and
it is clearly maintained only sparingly.

bug#47047: [External] : Re: bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Drew Adams]

> > Do we have some reason to deprecate this theme,
> > beyond someone finding that a new face "looks
> > out of place" when that theme is used?
> > It's always good to see an actual reason.
> 
> FWIW, I would personally object to removing a theme 
> on non-technical grounds.
> 
> In any case, you objected, and AFAIU you are still the maintainer so in
> that sense there is nothing to discuss here.  The theme is staying, at
> least until our maintainers say otherwise (the same as for all things).
> 
> As for reasons to remove a theme, I wrote before:
> 
>     "We have more than one theme that is buggy, has low coverage and/or
>     is not maintained, so maybe this is something we should think
>     about."
> 
> I can't say if it is buggy or not, but I think it has low coverage, and
> it is clearly maintained only sparingly.

FWIW, I agree with what you wrote there.

Except for a few nits:

1. IMO, bugginess of a theme should matter (should
   be thought about, as you put it), but low usage
   (coverage?) should not.  Why remove a theme just
   because it's seldom used?

2. Once again: I have NOT objected to deleting the
   theme.  I asked about technical reasons to do so.

3. I have no idea who the "maintainer" of that theme is.
   We were asked to contribute themes when custom themes
   became a possibility, and I sent that one.

bug#47047: [External] : Re: bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Stefan Kangas]

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

> 1. IMO, bugginess of a theme should matter (should
>    be thought about, as you put it), but low usage
>    (coverage?) should not.  Why remove a theme just
>    because it's seldom used?

What I mean by coverage is that it has only few faces defined, which
leads to inconsistent results.

I don't think we have any way of knowing how much it is used, so that
will be a hard metric to apply.

(We rarely see bug reports for them, however, which is some indication.)

> 3. I have no idea who the "maintainer" of that theme is.
>    We were asked to contribute themes when custom themes
>    became a possibility, and I sent that one.

That was a commendable initiative on your part.

The question I am thinking about is what to do about it now.  Perhaps we
(read: our users) aren't well served by unmaintained/incomplete themes?
Perhaps there are other themes that we would want to include (see
modus-themes)?  These are the issues that interest me.

Second.  Conventionally, when there is only an "Author" but no
"Maintainer" line, the author is also the maintainer.  If you don't
consider yourself the maintainer, and no one else wants to step up, the
conventional thing would be to add a line "Maintainer: emacs-devel".
That's my understanding at least.

bug#47047: [External] : Re: bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Drew Adams]

> > 1. IMO, bugginess of a theme should matter (should
> >    be thought about, as you put it), but low usage
> >    (coverage?) should not.  Why remove a theme just
> >    because it's seldom used?
> 
> What I mean by coverage is that it has only few faces defined, which
> leads to inconsistent results.

I see.  (I took a guess that you meant usage.)

What do you mean by "faces defined"?  Do you mean new
faces added by the theme, or existing faces redefined
by the theme, or something else?

Existing faces that are not redefined are nevertheless
covered (still defined), I'd think.

What inconsistent results have you identified?  What
kinds of inconsistency?

> > 3. I have no idea who the "maintainer" of that theme is.
> >    We were asked to contribute themes when custom themes
> >    became a possibility, and I sent that one.
> 
> That was a commendable initiative on your part.
> 
> The question I am thinking about is what to do about it now.

Why do you think you need to do anything "about it" now?


> Perhaps we (read: our users) aren't well served by
> unmaintained/incomplete themes?

As you say, users can report bugs.

In what way do you find it unmaintained or incomplete?
Has something needed to be changed, for maintenance
reasons?

There's plenty of code that's part of Emacs that hasn't
been changed an iota over the years, but still works.
Does that mean that it's necessarily unmaintained or
incomplete?  Certainly any code could be enhanced, but
that's something different, and not a requirement for
its continuation.

> Perhaps there are other themes that we would want to include (see
> modus-themes)?  These are the issues that interest me.

That's orthogonal to your bringing up the light-blue theme.

> Conventionally, when there is only an "Author" but no
> "Maintainer" line, the author is also the maintainer.  If you don't
> consider yourself the maintainer, and no one else wants to step up, the
> conventional thing would be to add a line "Maintainer: emacs-devel".
> That's my understanding at least.

If that's conventional, please feel free to go ahead
and add such a line.  I guess that would be an act of
"maintenance", but I won't tell anyone you're doing
maintenance. ;-)

Anything more critical than the missing "Maintainer"
designation?

bug#47047: [External] : Re: bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Stefan Kangas]

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

> What do you mean by "faces defined"?  Do you mean new
> faces added by the theme, or existing faces redefined
> by the theme, or something else?
>
> Existing faces that are not redefined are nevertheless
> covered (still defined), I'd think.

I mean that the theme makes no special effort to support various modes.
So you might have a theme with a background color that is very close to
the foreground of a face defined in some package, leaving things
completely unreadable.  I've seen it many, many times.

> What inconsistent results have you identified?  What
> kinds of inconsistency?

I mean, you can literally just open up any special-mode and have a look.
For example, with `light-blue-theme', the eshell prompt is all but
unreadable, and `eshell-prompt' is not defined in the theme itself.

If you don't like that example, try some other modes like Gnus, notmuch,
mu4e, ERC, etc.  Whatever you like.  You will find problems, I promise,
and you won't even have to dig deep.

There is just no way to theme Emacs by just throwing some 25 odd face
definitions in a theme and call it a day.  Take a look at
e.g. manoj-dark.el for something a bit more realistic.

> There's plenty of code that's part of Emacs that hasn't
> been changed an iota over the years, but still works.
> Does that mean that it's necessarily unmaintained or
> incomplete?  Certainly any code could be enhanced, but
> that's something different, and not a requirement for
> its continuation.

I'm talking about themes that are very old, unmaintained and not very
complete.

In any case, I don't think we are going to get anywhere by just
exchanging emails in this already closed bug report.  I hope I made my
reasoning somewhat more clear at least.

bug#47047: [External] : Re: bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Drew Adams]

> I mean that the theme makes no special effort to support various modes.

Correct.  There can be any number of "various modes",
from any number of sources, which use color in any
number of ways.

> So you might have a theme with a background color that is very close to
> the foreground of a face defined in some package, leaving things
> completely unreadable.  I've seen it many, many times.

Sure, you might.  Same with `emacs -Q'.  Nothing
prevents a mode from doing anything its designer
wants to do.

> For example, with `light-blue-theme', the eshell prompt is all but
> unreadable, and `eshell-prompt' is not defined in the theme itself.

If the eshell prompt uses a face that requires
customizing to play well with that theme, then
you can customize its face or use a mode hook
or...  Or not use that theme, if you use eshell.

> If you don't like that example, try some other modes like Gnus,
> notmuch, mu4e, ERC, etc.  Whatever you like.  You will find problems, I promise,
> and you won't even have to dig deep.

I believe you.  See above.

> There is just no way to theme Emacs by just throwing some 25 odd face
> definitions in a theme and call it a day.  Take a look at
> e.g. manoj-dark.el for something a bit more realistic.

If you expect a theme to be the end-point and
be-all, then sure.  If you take it as a starting
point then things are different.

> > There's plenty of code that's part of Emacs that hasn't
> > been changed an iota over the years, but still works.
> > Does that mean that it's necessarily unmaintained or
> > incomplete?  Certainly any code could be enhanced, but
> > that's something different, and not a requirement for
> > its continuation.
> 
> I'm talking about themes that are very old, unmaintained and not very
> complete.

Your idea of "complete" is quite pervasive/intrusive,
it seems.  A theme doesn't have to be a do-all end
in itself.  It can be, and perhaps people are now
used to more themes being along those lines.  But it
need not be (IMHO).

> In any case, I don't think we are going to get anywhere by just
> exchanging emails in this already closed bug report.  I hope I made my
> reasoning somewhat more clear at least.

Yes, now it's clear; thank you.  I think there's
more than one kind/level of theming that can be
useful, including things you'd call incomplete.
We need not agree as to what constitutes a theme
or what's needed for a theme to be of some use.

bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> The themes are loaded via `load-theme', aren't they?  (I don't really
>> know much about how themes work internally.)  If so, it looks pretty
>> trivial to make that function check whether there's the theme symbol has
>> been made obsolete, and then output a warning...
>
> Sounds reasonable.

I've now implemented this, and I'll be pushing it to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've now implemented this, and I'll be pushing it to Emacs 29.

Thanks!

bug#47047: 28.0.50; 'help-key-binding' face's background sub-optimal

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> I've now implemented this, and I'll be pushing it to Emacs 29.
>
> Thanks!

Now done, and I've made the light-blue theme obsolete at the same time.
So if I skim this bug report correctly, that means that the issues here
are covered, and I'm closing this bug report.  (But it was a very light
skimming; if there is more to be done here, please respond to the
debbugs address and we'll reopen.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no