From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#28400: 26.0.50; lcms2 bindings Date: Mon, 11 Sep 2017 18:01:45 +0300 Message-ID: <831sndth2e.fsf@gnu.org> References: <877ex7yiph.fsf@holos> <83shfvvkme.fsf@gnu.org> <20170910220422.GA14577@holos.localdomain> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1505142214 18853 195.159.176.226 (11 Sep 2017 15:03:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 11 Sep 2017 15:03:34 +0000 (UTC) Cc: 28400@debbugs.gnu.org To: Mark Oteiza Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 11 17:03:20 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drQEx-0003wY-9Q for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Sep 2017 17:03:11 +0200 Original-Received: from localhost ([::1]:58267 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drQF4-0002pa-Dx for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Sep 2017 11:03:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drQEu-0002nI-Hc for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 11:03:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drQEo-00061P-PJ for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 11:03:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53191) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1drQEo-00061G-MD for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 11:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1drQEo-0005eC-F6 for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 11:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Sep 2017 15:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28400 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28400-submit@debbugs.gnu.org id=B28400.150514212921644 (code B ref 28400); Mon, 11 Sep 2017 15:03:02 +0000 Original-Received: (at 28400) by debbugs.gnu.org; 11 Sep 2017 15:02:09 +0000 Original-Received: from localhost ([127.0.0.1]:33639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drQDx-0005d2-8K for submit@debbugs.gnu.org; Mon, 11 Sep 2017 11:02:09 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46608) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drQDv-0005cp-Ks for 28400@debbugs.gnu.org; Mon, 11 Sep 2017 11:02:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drQDi-0004Uo-HJ for 28400@debbugs.gnu.org; Mon, 11 Sep 2017 11:02:02 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drQDi-0004Uk-Di; Mon, 11 Sep 2017 11:01:54 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4326 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1drQDg-0000hD-PZ; Mon, 11 Sep 2017 11:01:54 -0400 In-reply-to: <20170910220422.GA14577@holos.localdomain> (message from Mark Oteiza on Sun, 10 Sep 2017 18:04:22 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:136781 Archived-At: > Date: Sun, 10 Sep 2017 18:04:22 -0400 > From: Mark Oteiza > 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.