Re: Introducing face in comments for various modes

[Thibaut Verron <thibaut.verron@gmail.com>]

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.