From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mirek Kaim Newsgroups: gmane.emacs.devel Subject: RE: Turning off colorization Date: Tue, 11 Nov 2014 18:58:56 +0100 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="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1415728781 20967 80.91.229.3 (11 Nov 2014 17:59:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Nov 2014 17:59:41 +0000 (UTC) Cc: "nljlistbox2@gmail.com" , "rms@gnu.org" , "emacs-devel@gnu.org" , "cloos@jhcloos.com" , "larsi@gnus.org" , Eli Zaretskii To: Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 11 18:59:35 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 1XoFj4-0007pF-TF for ged-emacs-devel@m.gmane.org; Tue, 11 Nov 2014 18:59:35 +0100 Original-Received: from localhost ([::1]:50085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoFj4-0008Aa-Jq for ged-emacs-devel@m.gmane.org; Tue, 11 Nov 2014 12:59:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoFii-00088o-Bo for emacs-devel@gnu.org; Tue, 11 Nov 2014 12:59:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XoFic-0004RJ-FF for emacs-devel@gnu.org; Tue, 11 Nov 2014 12:59:12 -0500 Original-Received: from col004-omc2s17.hotmail.com ([65.55.34.91]:56554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoFiU-0004PC-1X; Tue, 11 Nov 2014 12:58:58 -0500 Original-Received: from COL131-W63 ([65.55.34.71]) by COL004-OMC2S17.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 11 Nov 2014 09:58:56 -0800 X-TMN: [p1aGm1BKJa0vymFNGEEkund22bRcjjVONfMoIjfNjQQ=] X-Originating-Email: [mirek.kaim@outlook.com] Importance: Normal In-Reply-To: X-OriginalArrivalTime: 11 Nov 2014 17:58:56.0684 (UTC) FILETIME=[29BA4EC0:01CFFDD9] X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 65.55.34.91 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:176771 Archived-At: > From: yuri.v.khan@gmail.com=0A= >=0A= > You=92re talking about 256 colors as if it were a whole lot.=0A= >=0A= > In fact=2C 256 is a very limited color space. It includes 16 base=0A= > colors=2C a 6=D76=D76 color cube=2C and some 24 shades of gray. The color= cube=0A= > is typically configured with rather light colors=2C suitable for use as= =0A= > foreground on black (hex RGB value starting at 0x5f or something). As=0A= > a consequence=2C there are very few dark non-gray colors in the=0A= > 256-color palette.=0A= =0A= it's what a lot of people have. there's nothing wrong with having support f= or true color terminals - if it's available=2C by all means=2C use it. some= fallback for those with 256 colors should exist=2C though. writing some co= nverter that maximizes contrast while preserving the hue as much as possibl= e should be doable=2C but that's not my point.=0A= =0A= my point is that current background and terminal/emacs theme shouldn't matt= er when rendering a website. terminal theme usually redefines base 16 color= s=2C right? checking the background color suggests doing some fancy matchin= g of the website palette to that background color=2C and possibly to all ba= se 16 colors as well. kinda pointless=2C imho. current background should NO= T be used. at all.=0A= =0A= agreed=2C mapping rgb to 256 (-16) colors is far from being perfect either= =2C but if that's the only (colorful) option available=2C there's no other = way without touching the current terminal theme.=0A= =0A= > Nowadays=2C nobody bothers about web-safe colors any more. We have the=0A= > Tango palette=2C the Solarized palette=2C and a zillion other palettes=2C= =0A= > none mapping well to the xterm space.=0A= =0A= it so happens that i am using solarized palette. 16 colors=2C defined as rg= b values in mintty config. works pretty well and doesn't have to do anythin= g with 256-color palette. one can change the base 16 colors on the fly usin= g escape codes to any rgb values whatsoever on quite a few terminals=2C eve= n those without full truecolor support=2C but that's changing the terminal = theme altogether and the escape codes vary across terminals as well as acro= ss the environment (screen=2C tmux)=2C so it's kinda useless here.=0A= =0A= > Instead of coming up with clever heuristics about color remapping=2C we= =0A= > had better push for true color support in terminal emulators=2C=0A= > libraries and applications.=0A= >=0A= > https://gist.github.com/XVilka/8346728=0A= =0A= as i've said=2C fallback for 256-color terminals should be in place=2C imho= . without remapping colors to the 256-color palette=2C probably the only sa= ne option to preserve readability on such terminals would be to render the = website in 24 shades of gray. far from perfect=2C but readable. i'm all for= truecolor support in all terminal emulators=2C but we're simply not there = yet.=0A= =0A= on different note=2C for truecolor terminals/gui mode=2C it would be possib= le to get a nice 'easy on the eyes' website rendering for those that don't = care about original website colors that much - and prefer solarized palette= . for each rgb color=2C hue would be preserved=2C but saturation would chan= ge and luminosity would be mapped to solarized values depending if it's a b= ackground or foreground color=2C for constant contrast across the website. = the mapping function would need to know if the rgb values describe foregrou= nd or background color=2C but that shouldn't be a problem for website rende= rer.=0A= =0A= proper mapping of rgb values to 256-color palette shouldn't be that hard th= ough=2C nor cpu intensive. the trick would be to map colors using foregroun= d-background pairs to preserve contrast=2C even at the cost of changing one= of the hues dramatically. it certainly wouldn't be as pretty as the trueco= lor original or - especially - truecolor solarized variant of the original= =2C but it should remain readable when done right. which is=2C i guess=2C t= he main point of all this.=0A= =0A= one more alternative i can think of is using 24 shades of gray together wit= h shades of a single (selectable) color for 'accents'. the renderer would h= ave to choose where to use those accents though (links/buttons/headers/what= ever)=2C but it would be easier to navigate than plain grayscale variant.= =0A= =0A= =0A= unic0rn=0A= =