unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Automatic face setting based on contrast?
Date: Sat, 09 Oct 2021 10:38:58 +0300	[thread overview]
Message-ID: <837demy7e5.fsf@gnu.org> (raw)
In-Reply-To: <87czofvt9z.fsf@gmail.com> (message from Tim Cross on Sat, 09 Oct 2021 12:45:17 +1100)

> 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.



  reply	other threads:[~2021-10-09  7:38 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87k0iub53g.fsf.ref@yahoo.com>
2021-10-03 13:38 ` Why has the light blue theme been made obsolete? Po Lu
2021-10-03 14:25   ` Stefan Kangas
2021-10-03 14:52     ` Stefan Kangas
2021-10-03 16:04       ` [External] : " Drew Adams
2021-10-17  4:04         ` Jean Louis
2021-10-17 11:30           ` Stefan Kangas
2021-10-17 17:08             ` Drew Adams
2021-10-17 17:32               ` Stefan Kangas
2021-10-17 19:24                 ` Drew Adams
2021-10-17 20:31                   ` Stefan Monnier
2021-10-17 22:53                     ` Drew Adams
2021-10-18  0:40                       ` Stefan Monnier
2021-10-17 17:07           ` Drew Adams
2021-10-05 21:15       ` Automatic face setting based on contrast? Richard Stallman
2021-10-05 21:20         ` Alexandre Garreau
2021-10-06 20:53           ` Richard Stallman
2021-10-05 23:00         ` [External] : " Drew Adams
2021-10-05 23:10         ` Stefan Kangas
2021-10-06  0:20           ` Po Lu
2021-10-06  1:01             ` Stefan Kangas
2021-10-07 22:22               ` Richard Stallman
2021-10-07 22:22           ` Richard Stallman
2021-10-08  0:49             ` Tim Cross
2021-10-08  6:57               ` Eli Zaretskii
2021-10-09  1:45                 ` Tim Cross
2021-10-09  7:38                   ` Eli Zaretskii [this message]
2021-10-09 23:29               ` Richard Stallman
2021-10-09 23:29               ` Richard Stallman
2021-10-06  1:39         ` Stefan Monnier
2021-10-07 12:32           ` Tyler Grinn
2021-10-07 12:52             ` Simon Pugnet
2021-10-07 13:36             ` Stefan Monnier
2021-10-07 22:23               ` Richard Stallman
2021-10-04  9:30   ` Why has the light blue theme been made obsolete? Lars Ingebrigtsen
2021-10-17  4:18     ` Jean Louis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=837demy7e5.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=theophilusx@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).