From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Face color changes Date: Tue, 28 Dec 2004 23:41:25 -0800 Message-ID: References: <01c4ec5e$Blat.v2.2.2$118dc080@zahav.net.il> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1104306230 23006 80.91.229.6 (29 Dec 2004 07:43:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 29 Dec 2004 07:43:50 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 29 08:43:40 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CjYUd-0002Z9-00 for ; Wed, 29 Dec 2004 08:43:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CjYfW-0003W2-DW for ged-emacs-devel@m.gmane.org; Wed, 29 Dec 2004 02:54:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CjYfH-0003Tj-Ku for emacs-devel@gnu.org; Wed, 29 Dec 2004 02:54:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CjYfE-0003SJ-Dd for emacs-devel@gnu.org; Wed, 29 Dec 2004 02:54:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CjYfE-0003RQ-9s for emacs-devel@gnu.org; Wed, 29 Dec 2004 02:54:36 -0500 Original-Received: from [141.146.126.230] (helo=agminet03.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CjYSa-0004tL-N9; Wed, 29 Dec 2004 02:41:33 -0500 Original-Received: from agminet03.oracle.com (localhost [127.0.0.1]) by agminet03.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iBT7fVqv001972; Tue, 28 Dec 2004 23:41:31 -0800 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by agminet03.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iBT7fUvZ001957; Tue, 28 Dec 2004 23:41:30 -0800 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id iBT7fT7Z029600; Wed, 29 Dec 2004 00:41:29 -0700 Original-Received: from dradamslap (dhcp-amer-csvpn-gw2-141-144-80-103.vpn.oracle.com [141.144.80.103]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id iBT7fSTA029593 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 29 Dec 2004 00:41:29 -0700 Original-To: "Eli Zaretskii" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <01c4ec5e$Blat.v2.2.2$118dc080@zahav.net.il> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:31571 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31571 Sorry for the long and tardy reply. This discussion should really be for after the release, since it deals with possible new features - feel free to ignore. Followups, if any, can be off-list. > Some people are just loathe to customize, are intimidated by > it, cannot figure out how to start, or are too lazy to try. > We should make it as easy as possible, but there will always > be some who don't get it. But Customize _is_ supposed to be ``as easy as possible''. It was added to Emacs to help users customize their session without resorting to Lisp and obscure data structures. Yes; Customize is _supposed_ to be as easy as possible, and it _is_ sometimes easier than resorting to Lisp. However, 1) there will always be some who don't get it, no matter how easy it seems to others, and 2) it would be even easier if light & dark background heuristics worked better. However, I used "customize" above with a small "c", and I really had in mind customization in general, not necessarily using Customize. In the message to which I replied you said: > To me, the most important thing is the ease of customizing. > I've seen users making do with atrociously unreadable faces, > just because they didn't want to bother figuring out how to > change them. I don't know if there is an easy > solution, but the problem is a real one. That sounded like you were saying that no solution to the problem of customizing faces existed at this time. Now it sounds like you are saying that there is a solution, but people either loathe it, are intimidated by it, or are too lazy to try it. I'm confused: what issue are we discussing and what is the point you wish to make? Sorry for the confusion. The last sentence quoted was meant to refer mainly to the problem described in the previous paragraph that I wrote: "it's difficult to find color heuristics that please most users on most displays most of the time." But it also applies to the ease-of-use problem. The problem I was speaking of is not just "customizing faces". Ease of use is a funny thing. Lots of people have complained, for instance, about Firefox's incremental page search, which is in fact _easier_ to use than, say, IE's "Find (on This Page)". (Firefox's is similar to Emacs's incremental search.) It generally turns out that 1) it's just not what they were used to or 2) they weren't aware of it or couldn't figure out how it worked. IOW, it is very easy to use, but you have to first find it, know what to expect, and let yourself get used to it. Ease of use involves dealing with all of these hurdles. To answer your question, this was my point: Making a set of colors fit one's needs and preferences is a general problem, and not one that has a simple solution. In Emacs or elsewhere. The problem is not the difficulty of changing an individual color setting. And ease of customizing is not equivalent to ease of using Customize to change a face. The general problem is one of easily finding and setting an appropriate _combination_ of colors. Color themes and light & dark background settings do make things easier in this regard. And no, they are not new. They could be improved - that's all. Improving the treatment of background settings (e.g. Juri's tweaks) will help. Adding a "medium" background setting might also help (or not - TBD). There are probably other suggestions that might make creating a personalized color scheme easier. It's easy to imagine a few, if you think of the current limitations. It can also help to think of how other applications deal with this challenge - it's not all specific to Emacs. Suppose you more-or-less like a particular color theme you come across, but you would like to try it a little lighter or darker or greener or with more contrast or with a couple of the colors swapped. Simple ways to make such color-scheme changes might be helpful. Allowing for use of different mini color schemes with different classes of frames might also help by providing more flexibility. I, for instance, want my special-display-buffer frames in one color scheme, minibuffer frame in another, Info frames in another, *Help* in another, *Completions* in another - and I want each of these to be easy to read and I want all of them to play well together in an overall color scheme. (OK, I'm an extreme case... Circuler ; il n'y a rien a voir...) I haven't tried it yet, but I noticed some work that seems to be along these lines at http://www.emacswiki.org/cgi-bin/wiki/ColorThemeMaker - it allows you to mix color themes, piecewise (not yet by dynamically blending/morphing). And you can apply color themes to specific frames. Various pieces of the puzzle are out there, but not integrated in a simple way, and other pieces are missing. I don't have the answers, but I think 1) there is a general problem, 2) we could do a little better, and 3) arriving at appropriate user color-scheme customization tools will require some experimentation and perhaps a little study of what is done in other applications. That doesn't mean I don't appreciate the tools we have now, BTW. Concerning the ease of use of the Customize UI (since you brought it up), I do think there is some room for improvement there as well. Users can get lost in the Customize forest (a problem not specific to colors). And changing and choosing colors and color combinations could be made more WYSIWYG and make use of more-direct manipulation. Grab an existing color theme, then pull and push on it here and there until you get what you really want, then save it - that kind of thing. As a start and by way of illustration, I wrote some commands that let you change the frame background color incrementally using the arrow keys or mouse wheel (WYSIWYG; no fiddling with color names). Similarly, you can change a face foreground or background incrementally. Doing something similar with color _combinations_ (e.g. color themes) - heuristically changing multiple face colors and the frame background color, together - would, I think, make color customization quite a bit easier. But it would no doubt involve a few fancy heuristics under the hood to keep it simple but still let you do just what you want. And it might involve defining (or helping users define) various frame-combination and color-combination "structures" - mapping targets for the mini color schemes I mentioned. What I applaud in Juri's light/dark background tweaks is not just the present fix, which may be minor, but the attempt to look algorithmically at how various colors appear together. Some colors of the same darkness nevertheless work well together; other colors, even of contrasting darkness, don't stand out against each other. A face color that works well at one font size might not work well at another. Monitors, eyeballs, and application needs are different - there are lots of variables. What makes various color combinations work or not, in general? I don't know, but I think we'll need some guidelines to begin to provide color-scheme modification tools that are flexible but easy to use. So, I repeat my point: it's not that easy to provide general, flexible ways to manipulate _sets_ of colors and still keep those manipulations easy. On the other hand, simple predefined color schemes and well-defined target structures can take users a fair distance. Just integrating color-theme.el and a color-theme gallery (perhaps Web-based) with Customize might help in this regard. Look at all the Windows XP users who, without any programming knowledge, are able to customize Windows to fit their fancies. Ask any 13-year-old how she does it - look over her shoulder. (I'm not suggesting we emulate Windows - we can do better.) How do Web-page designers and graphic artists use their software to put together color combinations? What kinds of tools do they find useful (palettes, color wheels, ...)? What kind of heuristics does their software use? Yes, the micro color solutions are there already in Emacs - we have each been able to do what we need. The general challenge or opportunity is also there, however: to help people get the color schemes they want easily. In one sense, it's a problem with no solution (personal taste). In another sense, there are no doubt things that can be done to make it easier to create and change color schemes. > Heuristics to deal with light and dark (and perhaps medium) > backgrounds are a real help in this regard: there is less to > customize. Coming up with heuristics that work well in more > cases is not easy, but would be helpful. > In this regard, I think Juri is making a good start. The dark and light backgrounds exist in Emacs for a long time, as do separate default colors for each case; Yes, of course. Juri didn't invent that. No, of course not. What Juri suggested is to change the definition of light and dark for a small portion of the colors, that's all. What I saw Juri doing was trying to improve the light and dark background heuristics, making corrections so that some light colors aren't considered dark, etc. It's the question he asked that I think is interesting. I don't see how this can ever remove the need for customizing colors. In my experience, color selection is very personal, akin to taste. No disagreement on either score. I'm not a color expert or a graphic artist. Maybe someone out there has a simple solution (tool) or two for custom color-combination that would be appropriate for Emacs? - Drew P.S. As food for thought only, the Emacs code I mentioned, which incrementally changes frame and face colors, is here: http://www.emacswiki.org/elisp/doremi-frm.el - look for commands `doremi-bg-rgb' and `doremi-face-fg-rgb'. The code is described here: http://www.emacswiki.org/cgi-bin/wiki/DoReMi.