From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.devel Subject: Re: Turning off colorization Date: Tue, 11 Nov 2014 08:32:39 +0700 Message-ID: References: <87a944cm3x.fsf@moondust.localdomain> <83r3xfs8mx.fsf@gnu.org> <83r3xeqfa9.fsf@gnu.org> <831tpbni05.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1415669584 15679 80.91.229.3 (11 Nov 2014 01:33:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Nov 2014 01:33:04 +0000 (UTC) Cc: "nljlistbox2@gmail.com" , "rms@gnu.org" , "emacs-devel@gnu.org" , "cloos@jhcloos.com" , Eli Zaretskii , "larsi@gnus.org" To: Mirek Kaim Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 11 02:32:58 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xo0KI-0000fC-CH for ged-emacs-devel@m.gmane.org; Tue, 11 Nov 2014 02:32:58 +0100 Original-Received: from localhost ([::1]:46140 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo0KH-000184-Rv for ged-emacs-devel@m.gmane.org; Mon, 10 Nov 2014 20:32:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo0K5-00017j-5k for emacs-devel@gnu.org; Mon, 10 Nov 2014 20:32:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xo0K3-0005Au-SG for emacs-devel@gnu.org; Mon, 10 Nov 2014 20:32:45 -0500 Original-Received: from mail-ig0-x235.google.com ([2607:f8b0:4001:c05::235]:56195) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo0K0-00058P-Lu; Mon, 10 Nov 2014 20:32:40 -0500 Original-Received: by mail-ig0-f181.google.com with SMTP id l13so171772iga.8 for ; Mon, 10 Nov 2014 17:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Q0DRsqGgk9LxbZ3X2a1M8EHGllwXspzsMF6dau9NBXE=; b=iWYzENbmsm+faUUm1NRjtZdNeUOsKCIcsyDpku/AXu5LnZvDlny3L9d3q4vO/FedfY RCiiGKTbWhgkR/7J4ZpKn7iFDI7kkuY8FmwG7XWHdIKUlaAwtYK05plRAyr9n1U+uNj4 tkSg1UwHxT28nK4Sw59PJz8NiuiDjc4V+VCEl++NiP7R9SphZx+VSdwD9ctAFo2c82nk ZwbPZCt3GtSZlIFQgYvxPg3E40ayeY50qCsQ6DqUV7HsvSnud9pPwrTWWwJjbpVHX6xO E1a0g5OG+jG+G8dj+q35YR/pG3WRqeacAR7/vB1iLjItngwUcbMY1Z6J7Y7r7XzywZMp c5rQ== X-Received: by 10.43.83.6 with SMTP id ae6mr27078557icc.16.1415669559983; Mon, 10 Nov 2014 17:32:39 -0800 (PST) Original-Received: by 10.107.48.3 with HTTP; Mon, 10 Nov 2014 17:32:39 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: wrmMzLDsmNZJj32KST4_FmrZ5ac X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::235 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:176729 Archived-At: On Tue, Nov 11, 2014 at 12:37 AM, Mirek Kaim wrote= : > it is website's author responsibility to make it readable. all that's nee= ded is proper display of all the colors defined. in that regard, turning of= f colorization for terminals unable to report their background color is kin= da pointless. all that matters is if 256 colors are supported - because if = not, then there's no sure way to display a website in readable manner witho= ut discarding all rainbowy stuff. on the other side, if 256 colors are supp= orted, then the current background shouldn't matter and in case of a websit= e display, shouldn't be used at all. You=E2=80=99re talking about 256 colors as if it were a whole lot. In fact, 256 is a very limited color space. It includes 16 base colors, a 6=C3=976=C3=976 color cube, and some 24 shades of gray. The color= cube is typically configured with rather light colors, suitable for use as foreground on black (hex RGB value starting at 0x5f or something). As a consequence, there are very few dark non-gray colors in the 256-color palette. The Web authoring guides of the =E2=80=9995s talked about =E2=80=9Cweb-safe= =E2=80=9D colors. It was assumed these colors could be displayed on any web-enabled device. Those were defined as a color cube with a linear step of 0x33 for each RGB axis, also giving a 6=C3=976=C3=976 cube, but different from t= he xterm defaults. Web-safe cube: 00 33 66 99 CC FF xterm cube: 00 5F 87 AF D7 FF Let=E2=80=99s see how web-safe values are rounded to xterm values. 00 =E2=86=92 00 error 0 33 =E2=86=92 5F error +44 decimal 66 =E2=86=92 5F error -7, notice aliasing 99 =E2=86=92 87 error -18 CC =E2=86=92 D7 error +11 notice gap FF =E2=86=92 FF error 0 So the web-safe palette, when approximated in xterm, becomes a 5=C3=975=C3= =975 color cube, aliasing the two darker shades of each axis and skipping the midrange AF value. If anybody uses the 33 and 66 colors as distinct, well, they are not so distinct any more. Nowadays, nobody bothers about web-safe colors any more. We have the Tango palette, the Solarized palette, and a zillion other palettes, none mapping well to the xterm space. Instead of coming up with clever heuristics about color remapping, we had better push for true color support in terminal emulators, libraries and applications. https://gist.github.com/XVilka/8346728