From: Eli Zaretskii <eliz@gnu.org>
To: Mark Oteiza <mvoteiza@udel.edu>
Cc: 28400@debbugs.gnu.org
Subject: bug#28400: 26.0.50; lcms2 bindings
Date: Mon, 11 Sep 2017 18:01:45 +0300 [thread overview]
Message-ID: <831sndth2e.fsf@gnu.org> (raw)
In-Reply-To: <20170910220422.GA14577@holos.localdomain> (message from Mark Oteiza on Sun, 10 Sep 2017 18:04:22 -0400)
> Date: Sun, 10 Sep 2017 18:04:22 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: 28400@debbugs.gnu.org
>
> >Is it really so much better than what we have now to justify requiring
> >yet another library to build Emacs? If it is, could you tell what are
> >the main advantages, or point to where those advantages are described?
>
> It was just much easier for me to hack existing code than figure out adding
> a new file and the configure.ac business. It would be much more
> sensible to offer it as an optional feature and expose color metrics as
> optional arguments, e.g.
>
> (color-distance COLOR1 COLOR2 &optional FRAME METRIC)
>
> where METRIC accepts two colors and returns a number.
Oh, I see. But in that case, I think adding a new file and the
configure.ac business is actually quite easy. Search configure.ac for
"libz", and you will see a typical example: it involves adding a new
"--with-FOO" option to configure, and then some pretty boilerplate
code to test whether some tell-tale header file is present, and tweak
the compilation/linking flags accordingly. The new file then should
have all of its body wrapped in "#ifdef HAVE_FOO..#endif", with only
config.h outside of that condition and maybe some simple predicate to
test for the feature existence; see xml.c for a good example. Then
add that new file to src/Makefile.in, and you are pretty much done.
As for color-distance, did you intend to replace or provide a better
alternative to similar functions in color.el?
> >Btw, 256 colors is not "small" by Emacs standards, because our color
> >approximation should (and does) work in 8-color terminals as well.
>
> Yes, I should have used a different word than "small". Approximations
> for smaller palettes is easier because the differences between
> individual members of the palette are much bigger. The 256 color
> palette (and larger) has many colors much closer to one another, and
> calculating perceptual differences between colors that are close
> requires a more sophisticated model.
So you are saying that tty-colors.el is too simplistic for ncolors
around 256? If so, perhaps this optional feature could provide
compatible alternatives to that?
Thanks.
next prev parent reply other threads:[~2017-09-11 15:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-09 15:50 bug#28400: 26.0.50; lcms2 bindings Mark Oteiza
2017-09-09 17:37 ` Eli Zaretskii
2017-09-10 22:04 ` Mark Oteiza
2017-09-11 15:01 ` Eli Zaretskii [this message]
2017-09-11 15:25 ` Mark Oteiza
2017-09-11 15:35 ` Eli Zaretskii
2017-09-11 23:10 ` Mark Oteiza
2017-09-12 15:53 ` Eli Zaretskii
2017-09-12 21:06 ` Mark Oteiza
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=831sndth2e.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=28400@debbugs.gnu.org \
--cc=mvoteiza@udel.edu \
/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).