all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Yilkal Argaw <yilkalargawworkneh@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Adding some convenience functions to color.el
Date: Fri, 09 Jun 2023 10:34:35 +0300	[thread overview]
Message-ID: <83sfb11438.fsf@gnu.org> (raw)
In-Reply-To: <CAJddU=oK8tvS8BK_7w-iugGxUwdJN_PMw=Hvj0jEeNjkm2mctg@mail.gmail.com> (message from Yilkal Argaw on Fri, 9 Jun 2023 10:26:57 +0300)

> From: Yilkal Argaw <yilkalargawworkneh@gmail.com>
> Date: Fri, 9 Jun 2023 10:26:57 +0300
> Cc: emacs-devel@gnu.org
> 
>   > From: Eli Zaretskii <eliz@gnu.org>
>   > We already have color-dark-p (and color-name-to-rgb to complement it),
>    > so I'm not sure I understand the rationale for these functions.  Can
>    > you explain more why you needed them? 
> 
> Sorry I totally missed color-dark-p. I did not check faces.el and color-dark-p was in faces.el.

They are now documented in the ELisp manual.

> Having color-name-to-hsl is just a convenience function to make it easier when working in some
> color spaces. Because some operations are easier in certain color spaces.

color.el already provides color-rgb-to-hsl and color-hsl-to-rgb, so
you should be able to easily work in the HSL space, and still call
functions that accept RGB arguments.

IMO, we already have a large and rich collection of color-related
functions, so adding more will run the risk to increase confusion and
produce inconsistencies.  (E.g., your proposed color-name-dark-p uses
a threshold for dark vs light colors that is different from what we
use in color-dark-p.)



      reply	other threads:[~2023-06-09  7:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-08 23:57 Adding some convenience functions to color.el Yilkal Argaw
2023-06-09  6:22 ` Philip Kaludercic
2023-06-09  6:55 ` Eli Zaretskii
2023-06-09  7:26   ` Yilkal Argaw
2023-06-09  7:34     ` Eli Zaretskii [this message]

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

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

  git send-email \
    --in-reply-to=83sfb11438.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=yilkalargawworkneh@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.