From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: face at point Date: Tue, 19 Nov 2002 08:47:14 +0200 (IST) Sender: help-gnu-emacs-admin@gnu.org Message-ID: References: <1mptt2drm5.fsf@Tempo.Update.UU.SE> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1037688534 20530 80.91.224.249 (19 Nov 2002 06:48:54 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 19 Nov 2002 06:48:54 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18E2Bn-0005Ky-00 for ; Tue, 19 Nov 2002 07:48:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18E2BE-0003gm-00; Tue, 19 Nov 2002 01:48:16 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18E2AN-0003Lc-00 for help-gnu-emacs@gnu.org; Tue, 19 Nov 2002 01:47:23 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18E2AJ-0003JG-00 for help-gnu-emacs@gnu.org; Tue, 19 Nov 2002 01:47:23 -0500 Original-Received: from is.elta.co.il ([199.203.121.2]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18E2AH-0003IU-00 for help-gnu-emacs@gnu.org; Tue, 19 Nov 2002 01:47:18 -0500 Original-Received: from is (is [199.203.121.2]) by is.elta.co.il (8.9.3/8.8.8) with SMTP id IAA10859 for ; Tue, 19 Nov 2002 08:47:15 +0200 (IST) X-Sender: eliz@is Original-To: help-gnu-emacs@gnu.org In-Reply-To: <1mptt2drm5.fsf@Tempo.Update.UU.SE> Errors-To: help-gnu-emacs-admin@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.help:3749 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:3749 On 19 Nov 2002, Fredrik Staxeng wrote: > >> If that has changed to something more reasonable, could you state the > >> new policy? > > > >You are being unfair to the Emacs maintainers. This issue was never > > I was talking about faces generally, not about specificially > about tty faces. Me too. The process I described touched many standard faces, on both tty's and graphic displays. > The default font-lock faces contain serveral > that has too low contrast Some of them are intentional, but I suspect most aren't. Please help us make them better by reporting the specific cases to gnu.emacs.bug. > the GNUS default faces use italics. This should be reported to the Gnus maintainers. I don't think Gnus faces were changed at all, Emacs just uses whatever the Gnus maintainers defined. This is also true in general for the optional packages that define their own cases, the only exception being (IIRC) Ediff. > Are you saying that these would be considered bugs today, rather > than "those complain about this are the people who are able > to change this"? If the default definitions of a face make it unreadable, that's a bug that should be reported, IMHO. If the default is readable but unpleasant or annoying, please report that as well, but in that case it's possible that it's a matter of personal taste. > >Are we talking about a tty? If so, you have only 8 colors to choose > >from, on most tty types, so I don't see how could Emacs consider > >shades that depend on a weight. > > That was one possible explanation why one face might work on > black-on-white, but not black-on-white. You mean "white-on-black", yes? > When I look at a computer screen and compare the impression from > the same face white-on-black versus black-on-white, I get the > imression that white-on-black is heavier than white-on-black > one. Are you suggesting that black-on-white faces use larger weight on displays that support this? If so, how much heavier? > >> Pick default colors from a defined color map, e.g. the Netscape cube. > >> Define a static mapping from those 216 colors to the EGA colors > >> that PC consoles support. Provide a color-restriction option to > >> Emacs so that maintainers can easily test the effect of the color > >> limitation. > > > >If I understand correctly what you are suggesting, this has been done > >already (although some parts, like the color restricting option, only > >exist in the CVS, not in the released versions). > > Presently, it's obvious that default colors are picked from rgb.txt. > Names like LightGoldenRod... I am suggesting that the should be of the > form '#xxyyzz' instead, where xx = 00, 33, 66, 99, cc, ff. Assuming we are talking about tty's, why is this important? On a tty, Emacs translates a color name into an equivalent of #xxyyzz using a built-in list (see tty-colors.el), so using names and #xxyyzz gives the same result. The names of the default colors are chosen so that the result of their translation give what we consider to be a reasonably good and readable appearance; doing the same with RGB won't change anything. > I had a look at the Lisp code in 21.2, and I didn't see any static > mapping. The mapping seemed to be dynamic, considering only the > color itself, and not the one is was supposed in contrast to. Sorry, I don't understand the problem, as this description is too terse for me. Could you please elaborate? > >Finally, the tty-color code supports character-mode displays that are > >not based on EGA (nor VGA) devices (e.g., xterm), so using EGA colors > >slightly differently on each text terminal. This makes the job of > >getting readable faces much harder. > > Theoretically there is no standard, but in practice there is. > Almost all people having colors on their tty are running: > a) console mode on Linux/*BSD, in case they have the EGA colors, > b) or they are running in a xterm, which in fact tries to be use the > same colors as EGA. Many people (including me) have changed those > to the six fully saturated colors. AFAIK, Unix consoles use an SVGA nowadays, not an EGA. SVGA has slightly different color definitions, IIRC. Moreover, SVGA can be programmed at startup to use different palette colors. Even more important, no two SVGAs (or EGAs, for that matter) have the same default colors. Just put two consoles of two different vendors side by side and observe. So text-mode colors _are_ different. I've seen more than a single case where a color combination that looked very readable on my VGA was reported as barely readable on someone else's. Enter xterm and its ilk: not only do these have different default definitions of the 16 colors (e.g., compare xterm with rxvt), but they are _configurable_ on the user level! Even if we discard the unreasonable cases whereby someone defines "green" as #ffffff, there's still a very large range of reasonable definitions, and some people actually do this. > >> Looking good is a much more ambitious goal. I'll settle for readable. > > > >That's our goal as well. > > But the description "look good" keeps kreeping in when the issue is > readability. Well, that's because we would like to have both ;-) Of course, readability is more important that "looking good", at least IMHO. > And finally, looking at the default colors in e.g. > font-lock, it's obvious to me that the Emacs maintainers don't really > understand these issues. That remark doesn't really help. For starters, it doesn't tell the maintainers how to do better. And I already said that the current defaults were subject to prolonged discussions and several phases of improvements. It would help much more to hear specific suggestions for improvement (these are better posted to emacs-devel@gnu.org).