Why has the light blue theme been made obsolete?

Why has the light blue theme been made obsolete?

[Po Lu]

Is there a particular pressing need addressed by the obsoletion of the
light blue theme?  At some point, I found the theme quite appealing, and
I think there are many other people who agree.

BTW, shouldn't the obsoletion be documented in NEWS?

Thanks.

Re: Why has the light blue theme been made obsolete?

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Is there a particular pressing need addressed by the obsoletion of the
> light blue theme?  At some point, I found the theme quite appealing, and
> I think there are many other people who agree.

See the discussion in Bug#47047: http://debbugs.gnu.org/47047

> BTW, shouldn't the obsoletion be documented in NEWS?

I think it should.

Re: Why has the light blue theme been made obsolete?

[Stefan Kangas]

Stefan Kangas <stefan@marxist.se> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
> > Is there a particular pressing need addressed by the obsoletion of the
> > light blue theme?  At some point, I found the theme quite appealing, and
> > I think there are many other people who agree.
>
> See the discussion in Bug#47047: http://debbugs.gnu.org/47047

Actually, let me go into some more detail here:

The reason for obsoleting it is that it is unmaintained and not very
complete.  With "complete", what is meant is that it has only a small
number of faces defined, which means that it produces bad results in
too many commonly used modes.  If it was maintained, someone would be
working on improving this, but this does take an interested party to
actually follow up on bug reports, add new faces as they appear in
Emacs, etc.

I made this point in the above bug report, but there is no way to
style Emacs with 25-50 face definitions.  It is very hard to put an
exact number on this, as e.g. some faces are inherited and therefore
more important, but realistically speaking you need at least twice
that to have a somewhat decent coverage.  Compare light-blue-theme.el
with manoj-dark-theme.el to see the difference I am talking about.

More generally, I think Emacs would be well served by a better curated
selection of default themes.  The already highly popular modus-themes
has been included in Emacs 28, which I think is a step forward, and I
hope they will see much use.  For Emacs 29, I intend to look around
for other themes to include.  I'm not sure there are any good ones
where copyright is not an issue, but that remains to be seen.

PS. Another idea: the note in NEWS could come with an explanation of
why it's deprecated, and that if anyone is interested in maintaining
and extending it, they should contact emacs-devel and we will consider
reversing its obsoletion.  With a bit of luck, we can get an
interested party to take action - perhaps even before the release of
Emacs 29.

RE: [External] : Re: Why has the light blue theme been made obsolete?

[Drew Adams]

> Actually, let me go into some more detail here:

I suggest that anyone really interested
read the bug #47047 bug thread instead of
just the "summary" that was presented here.

But 90% of that bug thread, and the bug it's
supposed to be about, has absolutely nothing
to do with themes or this theme deprecation.

Everything about this theme deprecation is a
diversion from the subject of that bug thread.
But that's where the "argument" behind the
deprecation was made - if you're interested.

Not that anyone _should_ be interested.  It's
all supremely UNimportant, IMHO, but it might
be indicative of something (what, I dunno).

I'm even surprised that anyone noticed (came
across) this deprecation.  Very surprised.

Re: Why has the light blue theme been made obsolete?

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> BTW, shouldn't the obsoletion be documented in NEWS?

This obsoletion doesn't seem NEWS-worthy.  People who are using the
theme will get a warning, and other people don't care.

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

Automatic face setting based on contrast?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I made this point in the above bug report, but there is no way to
  > style Emacs with 25-50 face definitions.  It is very hard to put an
  > exact number on this, as e.g. some faces are inherited and therefore
  > more important, but realistically speaking you need at least twice
  > that to have a somewhat decent coverage.

Is this something that could be fixed, in principle?  Could a theme
specify some faces manually, and then Emacs would adjust various other
faces automatically so as to contrast with some of those?

Currently, a face can inherit properties from another face.
Could there be a kind of contrast-inheritance where face A
is set automatically to contrast strongly with B, and contrast
somewhat with C and D?  Based on calculations on the RGB codes,
I imagine.

This would call for a bit of research, but if we got it to work,
specifying a good theme might become a lot easier.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Automatic face setting based on contrast?

[Alexandre Garreau]

Le mardi 5 octobre 2021, 23:15:46 CEST Richard Stallman a écrit :
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > I made this point in the above bug report, but there is no way to
>   > style Emacs with 25-50 face definitions.  It is very hard to put an
>   > exact number on this, as e.g. some faces are inherited and therefore
>   > more important, but realistically speaking you need at least twice
>   > that to have a somewhat decent coverage.
> 
> Is this something that could be fixed, in principle?  Could a theme
> specify some faces manually, and then Emacs would adjust various other
> faces automatically so as to contrast with some of those?
> 
> Currently, a face can inherit properties from another face.
> Could there be a kind of contrast-inheritance where face A
> is set automatically to contrast strongly with B, and contrast
> somewhat with C and D?  Based on calculations on the RGB codes,
> I imagine.
> 
> This would call for a bit of research, but if we got it to work,
> specifying a good theme might become a lot easier.

I think it would be waaaaay more straightforward to use HSL code instead 
of RGB.  RGB is the lowest level possible, but difficult to master as a 
human.  The most meaningful way to specify colors is with HSL, which is to 
me the most high level.  It also looks straightforward to *at least 
intuitively* see some contrast issues with HSL, if either the hue, 
saturation or luminosity are not different enough.  It also enables easier 
not only comparisons in general, but also transformations, shades, etc. to 
be done programmatically

But programmatic faces looks like a terrifically nice feature… somewhat 
like programmatic fonts from metafont from TeX (at least the two areas are 
close, it’s a shame they’re grew so walled from each other).

RE: [External] : Automatic face setting based on contrast?

[Drew Adams]

>   > I made this point in the above bug report, but there is no way to
>   > style Emacs with 25-50 face definitions.  It is very hard to put an
>   > exact number on this, as e.g. some faces are inherited and
>   > therefore
>   > more important, but realistically speaking you need at least twice
>   > that to have a somewhat decent coverage.
> 
> Is this something that could be fixed, in principle?  Could a theme
> specify some faces manually, and then Emacs would adjust various other
> faces automatically so as to contrast with some of those?

That would certainly be a welcome feature to add, so
that any theme that wanted to make use of it could.
It's a very good idea.

However, I don't think that themes should be thought
to be deficient if they don't predefine faces.

IMHO, it's fine for a theme to not define any faces,
just as it's fine for a theme to not set any variable
values.  And it's fine for a theme to define some
faces or variables but not others.

And it's fine for a theme to define 8 million faces
and variables, including - or not - faces and vars
defined by emacs -Q.

Re: Automatic face setting based on contrast?

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

>   > I made this point in the above bug report, but there is no way to
>   > style Emacs with 25-50 face definitions.  It is very hard to put an
>   > exact number on this, as e.g. some faces are inherited and therefore
>   > more important, but realistically speaking you need at least twice
>   > that to have a somewhat decent coverage.
>
> Is this something that could be fixed, in principle?  Could a theme
> specify some faces manually, and then Emacs would adjust various other
> faces automatically so as to contrast with some of those?
>
> Currently, a face can inherit properties from another face.
> Could there be a kind of contrast-inheritance where face A
> is set automatically to contrast strongly with B, and contrast
> somewhat with C and D?  Based on calculations on the RGB codes,
> I imagine.
>
> This would call for a bit of research, but if we got it to work,
> specifying a good theme might become a lot easier.

I think it would be hard to find something "perfect", but if the goal is
to get something "good enough" or even just "a bit better", then it
sounds more achievable.

solarized themes has an interesting concept, where you only need to
specify a few base colors that the rest of the theme is calculated from.

So here's a theme definition:

;; inspired vim's jellybeans color-theme
(solarized-create-theme-file-with-palette 'light 'solarized-jellybeans-light
  '("#202020" "#ffffff"
    "#ffb964" "#8fbfdc" "#a04040" "#b05080" "#805090" "#fad08a"
"#99ad6a" "#8fbfdc"))

You can also override individual faces in case the algorithm fails.

I have no idea how well suited this approach is for general use, but I
suspect that you end up with a theme that fits within very specific
parameters.

Another idea is semantic faces.  For example, instead of just having the
face `info-title-1', we would have a general face `title1' that a face
in a mode that implements headlines would inherit from.  We obviously
already have some semantic faces, like `font-lock-doc-face', but the
concept could perhaps be developed.

Re: Automatic face setting based on contrast?

[Po Lu]

Stefan Kangas <stefan@marxist.se> writes:

> I think it would be hard to find something "perfect", but if the goal is
> to get something "good enough" or even just "a bit better", then it
> sounds more achievable.
>
> solarized themes has an interesting concept, where you only need to
> specify a few base colors that the rest of the theme is calculated from.
>
> So here's a theme definition:
>
> ;; inspired vim's jellybeans color-theme
> (solarized-create-theme-file-with-palette 'light 'solarized-jellybeans-light
>   '("#202020" "#ffffff"
>     "#ffb964" "#8fbfdc" "#a04040" "#b05080" "#805090" "#fad08a"
> "#99ad6a" "#8fbfdc"))
>
> You can also override individual faces in case the algorithm fails.

It would be nice to have that package as part of Emacs, but it means the
contributors would have to sign copyright paperwork.  Would it be
possible, and if so, how long would it take?

Thanks.

Re: Automatic face setting based on contrast?

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> It would be nice to have that package as part of Emacs, but it means the
> contributors would have to sign copyright paperwork.  Would it be
> possible, and if so, how long would it take?

There are 23 contributors to that theme with more than 15 lines added by
my count, but some of them have already signed their papers.  How long
it would take depends principally on how willing the other contributors
are to cooperate, I guess.

I also assume we would need the cooperation of whoever is the maintainer
of that project.  Maybe they are willing to do most of the work, but
otherwise someone on our end would also need to take charge of following
up with all the copyright holders, etc.

Re: Automatic face setting based on contrast?

[Stefan Monnier]

> Currently, a face can inherit properties from another face.
> Could there be a kind of contrast-inheritance where face A
> is set automatically to contrast strongly with B, and contrast
> somewhat with C and D?  Based on calculations on the RGB codes,
> I imagine.

We discussed such things in the past and yes, it would be great.
There are various situations, one of them being to compute faces when
a theme is installed or when a face is defined, but there can also be
more dynamic cases where a face could adapt to the place where it's used
(i.e. the actual computation would be performed during redisplay).
Not sure if those two situations should be treated uniformly or if they
should be handled by different mechanisms.


        Stefan

Re: Automatic face setting based on contrast?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Could there be a kind of contrast-inheritance where face A
  > > is set automatically to contrast strongly with B, and contrast
  > > somewhat with C and D?  Based on calculations on the RGB codes,
  > > I imagine.

  > I think it would be waaaaay more straightforward to use HSL code instead 
  > of RGB.  RGB is the lowest level possible, but difficult to master as a 
  > human.  The most meaningful way to specify colors is with HSL, which is to 
  > me the most high level.

I'm not trying to talk about details such as which coordinate system to use.
If you get this to work, it will be an advance.
Work out the details as yo like.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Automatic face setting based on contrast?

[Tyler Grinn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Currently, a face can inherit properties from another face.
>> Could there be a kind of contrast-inheritance where face A
>> is set automatically to contrast strongly with B, and contrast
>> somewhat with C and D?  Based on calculations on the RGB codes,
>> I imagine.
>
> We discussed such things in the past and yes, it would be great.
> There are various situations, one of them being to compute faces when
> a theme is installed or when a face is defined, but there can also be
> more dynamic cases where a face could adapt to the place where it's used
> (i.e. the actual computation would be performed during redisplay).
> Not sure if those two situations should be treated uniformly or if they
> should be handled by different mechanisms.
>
>
>         Stefan
>
>

It seems to me that there will always be a choice to be made, or a range
of acceptable colors for contrast.  Maybe a less opinionated way to go
about this would be to limit the color picker in the customize face
buffer to accessible colors and show a warning for faces that are not
sufficiently contrasting.

One way to implement that would be to write a command to analyze all
faces in the current buffer.  That way, a theme author could enable a
major mode and see a list of all faces and an accessibility report.

-- 

Best,

Tyler

Re: Automatic face setting based on contrast?

[Simon Pugnet]

Tyler Grinn <tylergrinn@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> We discussed such things in the past and yes, it would be great.
>> There are various situations, one of them being to compute faces when
>> a theme is installed or when a face is defined, but there can also be
>> more dynamic cases where a face could adapt to the place where it's used
>> (i.e. the actual computation would be performed during redisplay).
>> Not sure if those two situations should be treated uniformly or if they
>> should be handled by different mechanisms.
>>
>>
>>         Stefan
>>
>>
>
> It seems to me that there will always be a choice to be made, or a range
> of acceptable colors for contrast.  Maybe a less opinionated way to go
> about this would be to limit the color picker in the customize face
> buffer to accessible colors and show a warning for faces that are not
> sufficiently contrasting.
>
> One way to implement that would be to write a command to analyze all
> faces in the current buffer.  That way, a theme author could enable a
> major mode and see a list of all faces and an accessibility report.

I remember reporting a bug with the color_distance function in xfaces.c
and as I remember that led to a detailed and interesting discussion
about how to calculate accurate colour distances. Here's the link to the
thread in case it's useful:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41544

Simon

Re: Automatic face setting based on contrast?

[Stefan Monnier]

> It seems to me that there will always be a choice to be made, or a range
> of acceptable colors for contrast.  Maybe a less opinionated way to go
> about this would be to limit the color picker in the customize face
> buffer to accessible colors and show a warning for faces that are not
> sufficiently contrasting.

FWIW, I wrote the previous message with the following use-case in mind:
define a face that makes the text more/less red, or one that
increases/decreases contrast, ...


        Stefan

Re: Automatic face setting based on contrast?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Another idea is semantic faces.  For example, instead of just having the
  > face `info-title-1', we would have a general face `title1' that a face
  > in a mode that implements headlines would inherit from.  We obviously
  > already have some semantic faces, like `font-lock-doc-face', but the
  > concept could perhaps be developed.

We already have quite a bit of this sort of inheritance, don't we?  It
would be easy to install more; it's a matter of detail.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Automatic face setting based on contrast?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > There are 23 contributors to that theme with more than 15 lines added by
  > my count, but some of them have already signed their papers.

If someone has written 20 lines, each of which is totally stereotyped
and just like other themes except for the choice of one number, I'd
say equivalent to 5 lines of code

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Automatic face setting based on contrast?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > FWIW, I wrote the previous message with the following use-case in mind:
  > define a face that makes the text more/less red, or one that
  > increases/decreases contrast, ...

It might be rather easy to make that work
on a terminal with lots of gradations of color.
The main hard part would be to know how much change is needed
for users to see it clearly.

However, on a tty with a limited set of colors it could be impossible.
If a mode depends on this to work in order to make the output comprehensible,
it would fail totally.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Automatic face setting based on contrast?

[Tim Cross]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Another idea is semantic faces.  For example, instead of just having the
>   > face `info-title-1', we would have a general face `title1' that a face
>   > in a mode that implements headlines would inherit from.  We obviously
>   > already have some semantic faces, like `font-lock-doc-face', but the
>   > concept could perhaps be developed.
>
> We already have quite a bit of this sort of inheritance, don't we?  It
> would be easy to install more; it's a matter of detail.

Over the years, I've seen a considerable growth in the number of faces
defined, which has made consistent definitions of themes somewhat
challenging. Running M-x list-display-faces on my system shows over 1100
face definitions, which seems excessive. While many of these do use
inheritance, many don't. This is unfortunate. It would be great if all
modes which define faces by default inherit from one of the semantic
font lock faces, allowing basic theme definitions to be possible by just
tweaking the much smaller number of semantic faces and leaving tweaking
of mode specific derived faces to the user when desired.

It would also be useful if there was some way of listing the defined
faces which showed which face they are derived/inherited from to make it
easier to see exactly what would be affected if you modify the 'parent'
face and which faces are not defined to inherit from one of the semantic
faces (and could be a possible candidate for redefining to inherit from
a semantic face).

Re: Automatic face setting based on contrast?

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Fri, 08 Oct 2021 11:49:06 +1100
> 
> Over the years, I've seen a considerable growth in the number of faces
> defined, which has made consistent definitions of themes somewhat
> challenging. Running M-x list-display-faces on my system shows over 1100
> face definitions, which seems excessive.

In "emacs -Q", I see only 114 faces in that display.

> While many of these do use
> inheritance, many don't. This is unfortunate. It would be great if all
> modes which define faces by default inherit from one of the semantic
> font lock faces, allowing basic theme definitions to be possible by just
> tweaking the much smaller number of semantic faces and leaving tweaking
> of mode specific derived faces to the user when desired.

I think tweaking 100+ faces is not much easier than tweaking 1000.
Both border on the impractical.

> It would also be useful if there was some way of listing the defined
> faces which showed which face they are derived/inherited from to make it
> easier to see exactly what would be affected if you modify the 'parent'
> face and which faces are not defined to inherit from one of the semantic
> faces (and could be a possible candidate for redefining to inherit from
> a semantic face).

That sounds like a simple Grep job to me.

Eventually, I don't think there's a good solution to color contrast
that relies on manual tweaking of the faces.

Re: Automatic face setting based on contrast?

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tim Cross <theophilusx@gmail.com>
>> Date: Fri, 08 Oct 2021 11:49:06 +1100
>> 
>> Over the years, I've seen a considerable growth in the number of faces
>> defined, which has made consistent definitions of themes somewhat
>> challenging. Running M-x list-display-faces on my system shows over 1100
>> face definitions, which seems excessive.
>
> In "emacs -Q", I see only 114 faces in that display.
>

which makes me wonder why so many packages feel it necessary to add new
faces rather than just leverage off the 'default' faces. Would not be as
challenging if all those additional faces defaulted to inherit from one
of the 114 'default' faces, but unfortunately, many don't.


>> While many of these do use
>> inheritance, many don't. This is unfortunate. It would be great if all
>> modes which define faces by default inherit from one of the semantic
>> font lock faces, allowing basic theme definitions to be possible by just
>> tweaking the much smaller number of semantic faces and leaving tweaking
>> of mode specific derived faces to the user when desired.
>
> I think tweaking 100+ faces is not much easier than tweaking 1000.
> Both border on the impractical.
>

Agreed. However, not all of those 114 are 'semantic' faces. If the
default for each non-semantic face was to inherit from the semantic
faces, then most themes would be able to be defined via setting the
handful of semantic faces and leave more specific customization to the
end user who want to tweak the them in some manner.

>> It would also be useful if there was some way of listing the defined
>> faces which showed which face they are derived/inherited from to make it
>> easier to see exactly what would be affected if you modify the 'parent'
>> face and which faces are not defined to inherit from one of the semantic
>> faces (and could be a possible candidate for redefining to inherit from
>> a semantic face).
>
> That sounds like a simple Grep job to me.
>

Hmm, not sure it is that simple given grep is line based and face
definitions can be spread over multiple lines. However, once you have
gathered the list of faces, it wouldn't be too hard to iterate over them
to extract which ones are inherited.

What I was thinking of was a display which would show the inheritance
hierarchy, possibly in some sort of tree form to give an overview so
that you could not just tell which faces inherited, but where they
inherited from.

In some respects, the ability to add new faces is possibly a little too
easy and has encouraged an over proliferation of faces. This makes
consistent theming much harder than necessary.  

> Eventually, I don't think there's a good solution to color contrast
> that relies on manual tweaking of the faces.

I'm not convinced there is a good automatic solution which won't also
need some manual tweaking, especially given how quickly the number of
faces blows out once you add some additional packages. While automatic
contrast setting can help, manual tweaking will still be necessary.
Consistent use of inheritance from the core semantic faces would make
this easier.

One challenge with automatic contrast setting is that it has no way to
take aesthetics into account - you can get high contrast colours which
are simply unappealing. This is still better than the current situation
when you unexpectedly come across a face which is unreadable because it
has not been set to a suitable contrast for the current theme.  This
would be less of an issue if all these additional faces inherited from
the core semantic face by default. The code to ensure adequate contrast
would then only need to consider those semantic faces. 

Re: Automatic face setting based on contrast?

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 09 Oct 2021 12:45:17 +1100
> 
> > In "emacs -Q", I see only 114 faces in that display.
> 
> which makes me wonder why so many packages feel it necessary to add new
> faces rather than just leverage off the 'default' faces.

Because face changes are generally global for the entire frame (and if
you are not careful, for the entire session).  So changing a face used
by other modes would change the appearance of those other modes as
well.

> Would not be as challenging if all those additional faces defaulted
> to inherit from one of the 114 'default' faces, but unfortunately,
> many don't.

I don't see the significance of inheriting in this respect.  It still
creates a separate face, and if the attributes are changed (as they
necessarily will be), the effect on customization will be the same.
Perhaps you assume that the new face will keep the same colors of the
parent one, but I see no reason to make such an assumption, when the
purpose of the face is different.  The font-lock faces aren't made to
make parts of the code stand out, whereas many other faces need to do
precisely that.  So the considerations for choosing the colors are
different from the get-go.

> > I think tweaking 100+ faces is not much easier than tweaking 1000.
> > Both border on the impractical.
> 
> Agreed. However, not all of those 114 are 'semantic' faces. If the
> default for each non-semantic face was to inherit from the semantic
> faces, then most themes would be able to be defined via setting the
> handful of semantic faces and leave more specific customization to the
> end user who want to tweak the them in some manner.

See above: I don't see how this could be true in practice.

> What I was thinking of was a display which would show the inheritance
> hierarchy, possibly in some sort of tree form to give an overview so
> that you could not just tell which faces inherited, but where they
> inherited from.

Feel free to develop this.  But note that a face can inherit from
several faces, so this is not exactly a hierarchy in its classical
sense.

> In some respects, the ability to add new faces is possibly a little too
> easy and has encouraged an over proliferation of faces. This makes
> consistent theming much harder than necessary.  

I see no way around that.

> > Eventually, I don't think there's a good solution to color contrast
> > that relies on manual tweaking of the faces.
> 
> I'm not convinced there is a good automatic solution which won't also
> need some manual tweaking, especially given how quickly the number of
> faces blows out once you add some additional packages. While automatic
> contrast setting can help, manual tweaking will still be necessary.

Tweaking should only be needed to account for subjective differences
in perception of colors, which would mean adjusting the color
difference that makes the contrast "good enough".  That's far cry from
having to adjust hundreds of faces.

> Consistent use of inheritance from the core semantic faces would make
> this easier.

As I explain above, I think this is overly optimistic.

> One challenge with automatic contrast setting is that it has no way to
> take aesthetics into account - you can get high contrast colours which
> are simply unappealing.

Making that hypothetical feature understand and avoid bad color
combinations should not be too hard.

Re: Automatic face setting based on contrast?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Would you like to propose inheritance definitions for some faces
that currently are defined without them?

Please check the face is defined inside the Emacs distribution or ELPA
-- those are the ones we can fix.  If you're suggesting an improvement
in a face defined elsewhere, please convey the suggestion to the
developer of that package or someone else who is in a position to
consider the change,

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Automatic face setting based on contrast?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It would also be useful if there was some way of listing the defined
  > faces which showed which face they are derived/inherited from to make it
  > easier to see exactly what would be affected if you modify the 'parent'
  > face and which faces are not defined to inherit from one of the semantic
  > faces (and could be a possible candidate for redefining to inherit from
  > a semantic face).

Perhaps list-faces-display should omit the faces that inherit completely
from other faces.  There could be a way to request to show them.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [External] : Re: Why has the light blue theme been made obsolete?

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2021-10-03 19:06]:
> > Actually, let me go into some more detail here:
> I'm even surprised that anyone noticed (came
> across) this deprecation.  Very surprised.

I came across it now. And I was user of light blue theme for long
time, though I use various default themes.

I understand the theme is obsolete from 29.1 and when looking into
source it appears you are author Drew. 

Is it intended that after the selection of obsolete theme the theme
disappears from the list of themes? That is exactly what happened here
on my side. It is still in sources.

Cannot you, instead of making it obsolete, improve the theme so that
it remains as one of defaults for future? 

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Why has the light blue theme been made obsolete?

[Jean Louis]

I am user of light-blue and have many screenshots of it, and even
children in this house use light-blue theme. There is no other similar
default theme. It has good contrast, and is pleasant for eyes
depending of the environment. It is sad to see default theme not there
any more.

* Lars Ingebrigtsen <larsi@gnus.org> [2021-10-04 12:48]:
> Po Lu <luangruo@yahoo.com> writes:
> 
> > BTW, shouldn't the obsoletion be documented in NEWS?
> 
> This obsoletion doesn't seem NEWS-worthy.  People who are using the
> theme will get a warning, and other people don't care.

That reasoning is hard to understand. There will always be group of
people using A, but not using B. It is not logical, including the
reasoning in the bug report and removal of the light-blue theme.

What I would have expected is that whoever thinks there is problem
with light-blue is to improve it that it does not collide with other
themes, and not to remove it. It probably requires less lines then
what was written about it in bug report.

I do not expect any default Emacs themes to be removed. Especially not
for some slight reason. 

The obsoletion mechanism is not working well as then when theme
disappears from the list then it cannot be even turned off. I hope you
understand that:

[X] - light blue, once chosen, next invokation of theme selection does
not show it any more in the list. Then new themese are chosen, but
light blue cannot be disabled.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [External] : Re: Why has the light blue theme been made obsolete?

[Stefan Kangas]

Jean Louis <bugs@gnu.support> writes:

> Cannot you, instead of making it obsolete, improve the theme so that
> it remains as one of defaults for future?

I agree, that would clearly be the best outcome.  Could someone please
volunteer to do that?  If not, I think that the original arguments in
favour of obsoleting this theme still holds.  :-/

But that's just my opinion, of course.

RE: [External] : Re: Why has the light blue theme been made obsolete?

[Drew Adams]

> > > I'm even surprised that anyone noticed (came
> > > across) this deprecation.  Very surprised.
> 
> I came across it now. And I was user of light blue theme
> for long time, though I use various default themes.
> 
> I understand the theme is obsolete from 29.1 and when
> looking into source it appears you are author Drew.
> 
> Is it intended that after the selection of obsolete theme
> the theme disappears from the list of themes? That is
> exactly what happened here on my side. It is still in sources.
> 
> Cannot you, instead of making it obsolete, improve
> the theme so that it remains as one of defaults for future?

FWIW -

1. I have no intention of "improving" the theme,
   especially along the lines of what some (not
   I) might think is improvement.

   "Les goûts et les couleurs ne se discutent pas."

   (Culture and even geography can play a role
   in what appears to one person as dull or too
   noisy can appear to another as balanced or
   fresh.  A winter landscape far from the
   equator presents a different palette from
   one near the equator.)

2. Anyone is free to take the light-blue theme
   and run with it - "improve" it any way they
   see fit.  Or not.  It's free software.

3. I don't use any themes, myself.  My personal
   setup does use something similar to the frame
   parameters of the light-blue theme, for most
   frames.  But see #7, below.

4. I offered the light-blue theme to Emacs as
   one color-scheme possibility.  I think it
   offers possibilities of good color contrast
   - as opposed to value contrast, which is
   what's important for accessibility.  (But I
   think it generally offers good value
   contrast also.)

   In particular, the background is light, but
   it's dark enough that some light colors are
   usable against it.  I think a wide range of
   colors, with different values (light-dark),
   can be used effectively with it.  That's
   maybe not true of a lot of themes (dunno).

   Of course, just because you _can_ use a wide
   range of colors with such a background
   doesn't mean you need to or you should.

5. I have in mind that _legibility_ of text is
   NOT the only criterion of interest (at least
   for someone who doesn't have particular
   visual accessibility difficulties).

   Text that you need to _read_ or study needs
   to have high contrast - that's for sure.
   No disagreement about that.

   And that applies to the details of _code_
   you need to study and work with closely.
   Such a need for legibility and study doesn't
   apply to keywords such as `defun' etc., IMO.
   Those are essentially labels.

   Some such, e.g. `error', are things to
   notice - you want them to stand out.  But
   their legibility isn't very important.  And
   other such labels are neither important to
   read nor important to stand out.

   Text that you need only to recognize or
   notice does NOT need to have high value
   contrast, and sometimes _color_ contrast, not
   just value contrast, can be important for
   making such text stand out.

   This should be obvious from our world:
   product packaging, advertising, magazines,
   etc.  Think "bling", if you must.  It's
   there for a reason.

   There's no hesitation to use different
   colors together that might nevertheless have
   similar, even the same, values (i.e., little
   or no value contrast).

   I haven't tried to research what's known
   about this; I've just assumed it.  The world
   around me proclaims that it's true.  (But
   shouts and appearances can deceive, which is
   why we have science - put it to the test.)

   But again, this takes nothing away from the
   truth that for _reading_, and perhaps even
   for spending long hours staring at a screen,
   it's likely that nothing beats high value
   contrast.

   (I think there were some studies long ago
   that showed that reading black text on pale
   green paper is easier on the eyes that black
   on white paper.  Of course, paper != screen.)

   I'm no expert on any of this.  I just passed
   along the parameters I use for most frames as
   a simple custom theme to Emacs.
 
6. As with everything I offer, I expect it might
   serve some as a starting point, or as food
   for thought.  If not, fine.  It was never my
   intention to provide a cut-&-dried, "complete",
   monolithic theme - one theme to rule them all.

   The criterion imposed now by Emacs Dev is
   apparently that Emacs should offer only such
   "complete" themes.  I don't see the point of
   such a strict rule, but so be it.

   On n'arrête pas le progrès. ;-)

7. Personally, as I say, I don't use _any_ theme. 
   I use a standalone minibuffer frame with
   particular frame parameters and faces; I use
   custom *Completions* and *Help* frames, with
   particular parameters; and I use particular
   parameters for frames dedicated to buffers
   with name matching `*...*'.  (That includes
   *info*.  And yes, Info is for reading, as
   well as recognizing things.  But there are
   also labels that need to stand out.)

   In other words, I use `default-frames-alist',
   `minibuffer-frame-alist', and
   `special-display-frame-alist'; and I use
   `special-display-buffer-names' together with
   functions that display *Completions* and
   *Help* frames specially (dynamic definition).

8. My general opinion about themes includes this:

   a. A theme _need not_ define lots of faces
   and variables.  And generally it's probably
   better for users if it does not do so.  (No
   one need agree.)

   That's the general nature of _color themes_:
   define only frame parameters.  (Variables
   are not even part of color themes - they
   were introduced for custom themes).

   https://www.emacswiki.org/emacs/ColorThemes

   https://www.emacswiki.org/emacs/CustomThemes

   b. A priori, there's nothing _wrong_ with a
   custom theme being all-inclusive & monolithic.
   But there's also nothing _right_ about that,
   and there' nothing wrong with it not being so.

9. The light-blue (custom) theme follows that
   minimal model of typical color themes.  It
   doesn't define variables or faces, leaving
   that up to you or to other themes you might
   want to use together with it.

   Composing themes that way is something that
   color themes did and were good at, IIRC.
   Custom themes don't, in general, play so well
   together, IIRC - they're not so additive.
   Don't protest if I'm wrong about that.  As I
   say, I don't use themes, and I'm no expert.

   (My libraries that let you browse and try out
   themes (Icicles and Do Re Mi) work equally
   well with color themes and custom themes.)

RE: [External] : Re: Why has the light blue theme been made obsolete?

[Drew Adams]

> But that's just my opinion, of course.

Fine, but let's be clear -

Your opinion ... and your proposal, and
your action, to get it removed.

Re: [External] : Re: Why has the light blue theme been made obsolete?

[Stefan Kangas]

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

>> But that's just my opinion, of course.
>
>Fine, but let's be clear -
>
> Your opinion ... and your proposal, and
> your action, to get it removed.

Actually it was not I but Lars that marked it as obsolete.

RE: [External] : Re: Why has the light blue theme been made obsolete?

[Drew Adams]

> >> But that's just my opinion, of course.
> >
> > Fine, but let's be clear -
> > Your opinion ... and your proposal, and
> > your action, to get it removed.
> 
> Actually it was not I but Lars that marked it as obsolete.

Yes, he did.  What I wrote still stands.

You proposed and pushed for the removal;
he blessed it (and in the context of a
completely different issue, no less).

This quote is my summary of what you did:

 You add a face [to Emacs] 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".

Re: [External] : Re: Why has the light blue theme been made obsolete?

[Stefan Monnier]

Drew Adams [2021-10-17 19:24:43] wrote:
> [...]

Patches are more effective than gripes, so if you're opposed to
obsoleting that theme, just send us patches.


        Stefan

RE: [External] : Re: Why has the light blue theme been made obsolete?

[Drew Adams]

> Patches are more effective than gripes, so if you're
> opposed to obsoleting that theme, just send us patches.

Patches to do what?  De-obsolete the theme?

My "gripe", as you say, was a response to Jean Louis,
to explain my position and lack of intention to "fix"
that theme.  Had he not posted and requested that, I
wouldn't have bothered to post my reply - what you
refer to as my "gripe".

https://lists.gnu.org/archive/html/emacs-devel/2021-10/msg01268.html

As I made clear in the bug thread (#47047), I'm
_not_  opposed to removing the theme.  Others, not
I, objected to that.  From the outset I said:

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

Dunno how that wasn't clear as a bell, but I've
had to repeat it several times now.

In other messages to the same bug thread:

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

and

  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.

and

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

I made clear that I don't see the point of deleting
it just because someone feels that a new face s?he
wants to add to Emacs looks "out of place" if that
theme gets used.  (The fault, dear Brutus... or ...
If it hurts then don't do that...)

But that's not a plea to keep it.  I have no stake
in the light-blue theme.  None.  Tie it in knots
and sink it in the Mariana Trench, for all I care.

Multiple messages to try to get across that simple
point - which you, in your reading (?) of my reply
to Jean Louis, seem not to have gotten either.
_________

FWIW, I don't agree that Emacs themes need to be
"complete", defining lots of faces and variables,
and trying to ensure that if someone adds a face
s?he'll not find it "out of place" with the theme.

Just one opinion.  You may call this too a "gripe",
if you like.  (Patches?)

Re: [External] : Re: Why has the light blue theme been made obsolete?

[Stefan Monnier]

Drew Adams [2021-10-17 22:53:11] wrote:
>> Patches are more effective than gripes, so if you're
>> opposed to obsoleting that theme, just send us patches.
> Patches to do what?  De-obsolete the theme?
> [...more gripes...]

Oh well,


        Stefan