[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.
- Introducing face in comments for various modes, Heime, 2022/12/11
- Re: Introducing face in comments for various modes, Stefan Monnier, 2022/12/11
- Re: Introducing face in comments for various modes, Heime, 2022/12/11
- Re: Introducing face in comments for various modes, Heime, 2022/12/11
- Re: Introducing face in comments for various modes, Thibaut Verron, 2022/12/12
- Re: Introducing face in comments for various modes, Heime, 2022/12/12
- Re: Introducing face in comments for various modes, Thibaut Verron, 2022/12/12
- Re: Introducing face in comments for various modes, Heime, 2022/12/12
- Re: Introducing face in comments for various modes, Thibaut Verron, 2022/12/12
- Re: Introducing face in comments for various modes, Heime, 2022/12/12
- Re: Introducing face in comments for various modes,
Thibaut Verron <=
- Re: Introducing face in comments for various modes, Heime, 2022/12/12
- Re: Introducing face in comments for various modes, Yuri Khan, 2022/12/12
- Re: Introducing face in comments for various modes, Thibaut Verron, 2022/12/12
- Re: Introducing face in comments for various modes, Christopher Dimech, 2022/12/12
- Re: Introducing face in comments for various modes, Christopher Dimech, 2022/12/12
- Re: Introducing face in comments for various modes, Stefan Monnier, 2022/12/12
- Re: Introducing face in comments for various modes, Christopher Dimech, 2022/12/13
- Re: Introducing face in comments for various modes, Stefan Monnier, 2022/12/12
- Re: Introducing face in comments for various modes, Jean Louis, 2022/12/13
- Re: Introducing face in comments for various modes, Heime, 2022/12/13