From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark Oteiza Newsgroups: gmane.emacs.bugs Subject: bug#28400: 26.0.50; lcms2 bindings Date: Mon, 11 Sep 2017 11:25:20 -0400 Message-ID: <20170911152520.GA11036@holos.localdomain> References: <877ex7yiph.fsf@holos> <83shfvvkme.fsf@gnu.org> <20170910220422.GA14577@holos.localdomain> <831sndth2e.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1505144241 4328 195.159.176.226 (11 Sep 2017 15:37:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 11 Sep 2017 15:37:21 +0000 (UTC) User-Agent: Mutt/1.9.0 (2017-09-02) Cc: 28400@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 11 17:37:15 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 1drQll-0000C6-1D for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Sep 2017 17:37:05 +0200 Original-Received: from localhost ([::1]:58470 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drQlp-0000Ne-0O for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Sep 2017 11:37:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drQbA-0007dz-DM for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 11:26:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drQb5-0008Eo-Vr for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 11:26:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53241) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1drQb5-0008EW-QS for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 11:26:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1drQb4-0006DB-Lb for bug-gnu-emacs@gnu.org; Mon, 11 Sep 2017 11:26:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mark Oteiza Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Sep 2017 15:26: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.150514352923820 (code B ref 28400); Mon, 11 Sep 2017 15:26:02 +0000 Original-Received: (at 28400) by debbugs.gnu.org; 11 Sep 2017 15:25:29 +0000 Original-Received: from localhost ([127.0.0.1]:33687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drQaW-0006C7-TD for submit@debbugs.gnu.org; Mon, 11 Sep 2017 11:25:29 -0400 Original-Received: from mail-qk0-f178.google.com ([209.85.220.178]:35241) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drQaV-0006Bt-Qk for 28400@debbugs.gnu.org; Mon, 11 Sep 2017 11:25:28 -0400 Original-Received: by mail-qk0-f178.google.com with SMTP id r141so19260917qke.2 for <28400@debbugs.gnu.org>; Mon, 11 Sep 2017 08:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udel-edu.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=lqqntv2lyE753Lav0FOJTMkCM+Ev7JC6VacCeTHz5go=; b=wooh/zhpdyPJo2TY5Nsrd3LfGZ9n6W5NJz+M78gpOVsiY66SqrUYjV4Oj/pd5VFRxv GHHd3g3no9xR8BbOcBVMGD5rO/O5VEEIkPjoLYofj6k0ovrvv4Lquw195q9q+tJjKWhb 32ikhXcYPaEN1kOdQl2PaHyfwzdyfJ24Ctcy9JRY5XtYXH/+wpMmMZ2kBD3wOy2wJa3l 1SVrDBF7nGKHLqH02t1GNT7oJvLAHx7V29GEFq5asqLoyJakW8pHlOt316T7sH/HEX+F UVQDCMl0Nz0BN7wZh0WO4U9NpZgeSFWKNYYspUBYoxQpo5a0BGAaU1O8YkdLIT/KMikE 3UiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=lqqntv2lyE753Lav0FOJTMkCM+Ev7JC6VacCeTHz5go=; b=n7wS3AefHOHhZmDjX3hD8l1wYgMqg301iADlPOJFe0dcOJIf/vn9YFktXM0iXsSWH5 C8W85ejdsN9hgD/Eeoqa74xHfpTO0bmiMXhbg5xXwoURkImCIKxpTidoiqNXAO7IwzRG ylfRFN5LMN4y0iSw0DyutflqI6HDC07jNFuY3TCNlvUZ6J8+iSN9hUFJ3NcY9zACf3xH Ju3uQfZVkTr22IOA3hmXV/xobOs6YbJTvB5XsZa3bk/d3pQleowrTT2JZns5jbAIrp2h V/WkQgSgK96Ps+EAcYdLZwsbnDhE2IwCsRqesDYId+D6VWiqD/I96iV4k7sXPMozsCvb bscQ== X-Gm-Message-State: AHPjjUjPUGsdWDUp4V5XYJJWOsrV2jjx6NDlO8enu0z/wlhmSOXQM77k 6XFD4+zP2Dcrl7IQQCXcQQ== X-Google-Smtp-Source: AOwi7QA8gm9waRJsvi0glbklW1LSQ1KxnMvZtS4vR3UUaTCabI59k5tB15ARV8RvGotu/FlY6kXprw== X-Received: by 10.55.209.155 with SMTP id o27mr16757967qkl.145.1505143521911; Mon, 11 Sep 2017 08:25:21 -0700 (PDT) Original-Received: from holos.localdomain (pool-173-67-36-61.bltmmd.fios.verizon.net. [173.67.36.61]) by smtp.gmail.com with ESMTPSA id b126sm6133448qka.54.2017.09.11.08.25.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 11 Sep 2017 08:25:21 -0700 (PDT) Original-Received: by holos.localdomain (Postfix, from userid 1000) id 6F27468E70; Mon, 11 Sep 2017 11:25:20 -0400 (EDT) Content-Disposition: inline In-Reply-To: <831sndth2e.fsf@gnu.org> 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:136787 Archived-At: On 11/09/17 at 06:01pm, Eli Zaretskii wrote: > > 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. Thanks, I'll attempt that. > As for color-distance, did you intend to replace or provide a better > alternative to similar functions in color.el? That is a good question. I've thought about it, but don't have a good answer. lcms2 could certainly replace some of the things in color.el, but if it's an optional feature I guess there are a number of ways to handle it. If we include lcms2.c providing its own 'cms or 'lcms2 feature, I guess featurep'ing things wouldn't be so bad. > > >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? It will get some interesting results. For instance, asking Emacs for #3d3535 (dark, slightly reddish grey) in a 256 color term will yield #5f005f (color-53, a strong purple) instead of color-235 or color-236 (dark greys). It does a good job overall, so I don't suggest changing it. > If so, perhaps this optional feature could provide > compatible alternatives to that? Sure, like the example above for color-distance, tty-colors-approximate could expose an extra optional argument and/or respond to a variable.