help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Introducing face in comments for various modes


From: Thibaut Verron
Subject: Re: Introducing face in comments for various modes
Date: Mon, 12 Dec 2022 13:17:23 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 12/12/2022 12:55, Heime wrote:
------- Original Message -------
On Monday, December 12th, 2022 at 10:50 AM, Thibaut Verron 
<thibaut.verron@gmail.com> wrote:


On 12/12/2022 11:20, Heime wrote:

------- Original Message -------
On Monday, December 12th, 2022 at 9:58 AM, Thibaut 
Verronthibaut.verron@gmail.com wrote:

On 12/12/2022 10:21, Heime wrote:

------- Original Message -------
On Monday, December 12th, 2022 at 8:49 AM, Thibaut Verron
thibaut.verron@gmail.com wrote:

Le lun. 12 déc. 2022 à 04:01, Heimeheimeborgia@protonmail.com a
écrit :

------- Original Message -------
On Monday, December 12th, 2022 at 2:24 AM, Heime
heimeborgia@protonmail.com wrote:

The colors of the standard themes are chosen with its (light)
background in mind. If you change that background, it is not
surprising that things fall apart.
Choosing colours with a light background in mind is the wrong approach
because colours produce far greater visual
impact.
There is no right or wrong approach, but individual preferences.
Standard metrics exist. The Gnu Project like many others, does not
want to use them.
You're moving the goalpost: the sentence I quoted claimed that "focusing
on a light background is the wrong approach".
Having worked with modus-themes, it was concluded that there exist greater
variations in possibilities with a dark background that with a light one.

Great for themes with a black background.

That doesn't make it "wrong" for a theme to have a light background.

It's already bad enough now with some packages defining their own faces
without at least inheriting from the standard ones.
Right.  My focus has been to provide colours with good metrics so that
people inherit from the standard ones.

That's called designing a theme. Aka the current approach. Which you have been arguing is wrong.

There are currently 5330 packages on Melpa. Do you plan to contact the
authors of all of them individually to get them to implement your
preferred colors?
To start using actual standards.  Absolutely, they should learn more and change
their packages.

Great. Good luck with that.

On the other hand, the current recommended approach is to inherit from existing faces and let theme designers (or users, if they choose to) populate those with suitable colors.

No need for package developers to implement standards, no need to learn about theme design, no need to change things to accommodate for user-preferred colors, and if you have a problem, only one bug report to file -- with the theme.

You shouldn't think of themes as "fixing the default choices"
(especially considering that you are the one "breaking" them by
insisting to use them with a background they weren't designed for).
Their purpose is to implement different choices in a consistent way.
Good design in much more important that consistency.
It's also much easier to achieve in a consistent system.
The argument is to design separately for light and also for dark background.
Emacs does have light and dark checks.

That's again, moving the point.

Yes, Emacs does have those checks, but it's just a different way of providing two themes for light and dark backgrounds. If done for full themes, it's only a formal change, between two separate theme definitions, or one with interleaved conditionals.

If done for only a subset of faces, leaving the others untouched, it's a poor-person's way to try to accommodate everything, but it's imperfect and it might be unreadable on themes which are far from the standard white or black (not to mention terminal users). For that use-case, it is usually preferred to find an existing face to inherit from, trusting the theme designers for this face to be rendered in a readable way.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]