Face color changes

Face color changes

[Juri Linkov]

I noticed that some face colors are bad choices.  The worst example
is "RosyBrown" used for font-lock-string-face on light backgrounds.
It has high intensity which corresponds to light colors.  No wonder
that this color is hardly visible on light backgrounds.

I got the formula from x_alloc_nearest_color_1 to calculate a dark color
nearest to "rosybrown".  The code is below:

(let* ((frame (selected-frame))
       (color-values (mapcar (lambda (v) (lsh v -8))
			     (x-color-values "rosybrown" frame)))
       (c-r (nth 0 color-values))
       (c-g (nth 1 color-values))
       (c-b (nth 2 color-values)))
  (list-colors-display
   (delq nil (mapcar
	      (lambda (c) (and (eq (color-mode (cadr c)) 'dark) (cadr c)))
	      (sort (mapcar
		     (lambda (c)
		       (let* ((c-values (mapcar
					 (lambda (v) (lsh v -8))
					 (x-color-values (car c) frame)))
			      (d-r (- c-r (nth 0 c-values)))
			      (d-g (- c-g (nth 1 c-values)))
			      (d-b (- c-b (nth 2 c-values))))
			 (list (+ (* d-r d-r) (* d-g d-g) (* d-b d-b)) (car c))))
		     (list-colors-duplicates))
		    (lambda (a b) (< (car a) (car b))))))
   "*Colors-Nearest*"))

(defun color-mode (bg-color)
  (let ((frame (selected-frame)))
    (if (let ((bg-color-values (x-color-values bg-color frame))
	      (white-values (x-color-values "white" frame)))
	  (>= (+ (* (nth 0 bg-color-values) 0.30)
		 (* (nth 1 bg-color-values) 0.59)
		 (* (nth 2 bg-color-values) 0.11))
	      (* (+ (* (nth 0 white-values) 0.30)
		    (* (nth 1 white-values) 0.59)
		    (* (nth 2 white-values) 0.11))
		 .5)))
	'light 'dark)))

It suggests to replace "rosybrown" by "plum4" or "PaleVioletRed4", and
"orchid" (for font-lock-builtin-face) by "MediumOrchid3" or "DarkOrchid3".

If this is correct, other face colors could be improved as well
to match their background mode (i.e. to use light colors on dark
backgrounds, and dark colors on light backgrounds).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Face color changes

[Miles Bader]

On Sun, Dec 26, 2004 at 09:57:38PM +0200, Juri Linkov wrote:
> I noticed that some face colors are bad choices.  The worst example
> is "RosyBrown" used for font-lock-string-face on light backgrounds.
> It has high intensity which corresponds to light colors.  No wonder
> that this color is hardly visible on light backgrounds.

I'd go farther to say that _many_ of the light-background default faces are
quite pathetically bad; however it's always in my experience been very hard
to form any consensus for change because of the fear that "users will mind"
(not to mention inevitable bickering over what new color to use).

[I use a dark background, so I reserve my energy for keeping those faces sane]

> If this is correct, other face colors could be improved as well
> to match their background mode (i.e. to use light colors on dark
> backgrounds, and dark colors on light backgrounds).

A nice idea, though any such formulaic judgment of color relationships should
be closely scrutinized.

-Miles
-- 
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house.  And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
  [George Carlin]

Re: Face color changes

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Sun, 26 Dec 2004 21:57:38 +0200
> 
> It suggests to replace "rosybrown" by "plum4" or "PaleVioletRed4", and
> "orchid" (for font-lock-builtin-face) by "MediumOrchid3" or "DarkOrchid3".
> 
> If this is correct, other face colors could be improved as well
> to match their background mode (i.e. to use light colors on dark
> backgrounds, and dark colors on light backgrounds).

IMHO, this is not the time to make such changes.  As Miles pointed
out, these issues tend to generate prolonged disputes with
characteristic difficulties to reach a consensus.  Also, changing a
bunch of face colors tends to prompt many other color-related changes,
which spread like a cancer.  Why start that now?  Especially since, as
your other message shows, it might be tricky to even agree on what is
``light'' and what is ``dark''.

Re: Face color changes

[Eli Zaretskii]

> Date: Sun, 26 Dec 2004 18:49:47 -0500
> From: Miles Bader <miles@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> I'd go farther to say that _many_ of the light-background default faces are
> quite pathetically bad

I'd say this is unlikely, since most users run Emacs on a light
background.  Pathetically bad colors would have caused massive
complaints.

Re: Face color changes

[Jan D.]

>> Date: Sun, 26 Dec 2004 18:49:47 -0500
>> From: Miles Bader <miles@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>> I'd go farther to say that _many_ of the light-background default 
>> faces are
>> quite pathetically bad
>
> I'd say this is unlikely, since most users run Emacs on a light
> background.  Pathetically bad colors would have caused massive
> complaints.

I do run Emacs on a light background.  "Pathetically bad" is an 
overstatement, but some face does make me think "What the..." the first 
time I see them.  But you get used to them after a while.

	Jan D.

Re: Face color changes

[Miles Bader]

> I'd say this is unlikely, since most users run Emacs on a light
> background.  Pathetically bad colors would have caused massive
> complaints.

I suppose the most vocal sort of users customized their faces long ago.

-Miles

Re: Face color changes

[Eli Zaretskii]

> Date: Mon, 27 Dec 2004 17:50:11 +0900
> From: Miles Bader <snogglethorpe@gmail.com>
> Cc: Miles Bader <miles@gnu.org>, juri@jurta.org, emacs-devel@gnu.org
> 
> I suppose the most vocal sort of users customized their faces long ago.

That's a possibility, yes.

Anyway, I'm not against changing the color defaults, I just don't
think now is the time to open that can of worms (again).

RE: Face color changes

[Drew Adams]

Yes, now is not the time.
Yes, the vanilla Emacs colors are often less than ideal for many
backgrounds.
Yes, it's difficult to find color heuristics that please most users on most
displays most of the time.

For after the release: I'd like to see trials of a third setting, for medium
backgrounds.

I use light backgrounds (LightBlue, LightSteelBlue, PaleGoldenrod, Thistle,
LavenderBlush2), but in fact many "light" backgrounds work with both 1)
faces that are lighter (but a different color) and 2) faces that are
darker - they act effectively as "medium" backgrounds. In any case, I've
never been able to take advantage of either the "light" or "dark" background
settings. I'm one of those "sort of users [who] customized their faces long
ago".

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.

 - Drew

Re: Face color changes

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <juri@jurta.org>, "Eli Zaretskii" <eliz@gnu.org>, <miles@gnu.org>
> Date: Mon, 27 Dec 2004 09:16:35 -0800
> 
> 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.

Is anything wrong with "M-x customize-face RET"?  It even has a
convenient entry point from the buffer created by "M-x
list-faces-display RET" (e.g., click mouse-2 on the face's name).

RE: Face color changes

[Drew Adams]

    Is anything wrong with "M-x customize-face RET"?  It even has a
    convenient entry point from the buffer created by "M-x
    list-faces-display RET" (e.g., click mouse-2 on the face's name).

No, nothing wrong with it. Everything is right with it.

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.

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.

Re: Face color changes

[Richard Stallman]

    I'd go farther to say that _many_ of the light-background default faces are
    quite pathetically bad; however it's always in my experience been very hard
    to form any consensus for change because of the fear that "users will mind"

Backward-compatibility is not important here; if people agree that a
certain color is inherently better for most users, I will gladly make
the change.

Re: Face color changes

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Mon, 27 Dec 2004 09:44:56 -0800
> 
> 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.

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?

> 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; Juri didn't invent that.  What
Juri suggested is to change the definition of light and dark for a
small portion of the colors, that's all.  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.

Re: Face color changes

[Richard Stallman]

    I do run Emacs on a light background.  "Pathetically bad" is an 
    overstatement, but some face does make me think "What the..." the first 
    time I see them.

We can change them now.  These changes won't break other things in
surprising ways.  So it is just a matter of finding a better choice of
face definitions.

That may not be easy, but at least it is doable in theory.

Re: Face color changes

[Richard Stallman]

    For after the release: I'd like to see trials of a third setting, for medium
    backgrounds.

I won't argue against it if someone wants to do it,
but I think this is much less important than making the existing
two options work well.  That is because black backgrounds and white
backgrounds are what beginners will have.  People who start to customize
the background color of Emacs will or course have to customize faces too,
and they won't feel that is anything wrong with Emacs.

Re: Face color changes

[Juri Linkov]

"Eli Zaretskii" <eliz@gnu.org> writes:
> Is anything wrong with "M-x customize-face RET"?

Yes.  In `custom-set-faces' it loses all conditions from the face
definition except the current one.  This means that saved faces are
the same on different environments.  Maybe this is one of the reasons
why users refrain from customizing faces.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Face color changes

[Juri Linkov]

"Eli Zaretskii" <eliz@gnu.org> writes:
> Anyway, I'm not against changing the color defaults, I just don't
> think now is the time to open that can of worms (again).

There are very few faces that need to be adjusted a little
to make them darker on light backgrounds.

Also, I recall the discussion about changing the yellow color of
Info-title-1-face on light background, but nothing was changed.
How about such change?

(defface Info-title-1-face
  '((((type pc) (class color))
     :foreground "yellow" :weight bold)
    (((type tty) (class color) (background dark))
     :foreground "yellow" :weight bold)
    (((type tty) (class color) (background light))
     :foreground "green" :weight bold)
    (t :height 1.2 :inherit Info-title-2-face))
  "Face for Info titles at level 1."
  :group 'info)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Face color changes

[Richard Stallman]

    It suggests to replace "rosybrown" by "plum4" or "PaleVioletRed4", and

Does anyone want to argue that this change would make things worse?
Does anyone want to argue for one or the other of those two choices?

    "orchid" (for font-lock-builtin-face) by "MediumOrchid3" or "DarkOrchid3".

Same two questions here.

Re: Face color changes

[Richard Stallman]

    > Is anything wrong with "M-x customize-face RET"?

    Yes.  In `custom-set-faces' it loses all conditions from the face
    definition except the current one.

Could you explain what you mean here?  This sounds like it could
be an important bug.  If so, we need to fix it, not act as if
it were immutable!

Re: Face color changes

[Eli Zaretskii]

> Cc: drew.adams@oracle.com, emacs-devel@gnu.org
> From: Juri Linkov <juri@jurta.org>
> Date: Tue, 28 Dec 2004 04:52:07 +0200
> 
> In `custom-set-faces' it loses all conditions from the face
> definition except the current one.  This means that saved faces are
> the same on different environments.

I think this is by design.  To make it behave differently, we need
first to design the desired result.  What would you like it to do,
exactly? modify only the definition that corresponds to the current
background mode, number of colors, display type, etc., and leave the
other definitions intact?

In general, Customize does not support customizations that are
portable across environments and/or platforms.  E.g., if you customize
something on Windows, the result is not conditioned by the appropriate
value of system-type.  Isn't the issue you raise similar?

> Maybe this is one of the reasons why users refrain from customizing
> faces.

Do we know for sure that ``users refrain from customizing faces''?  If
so, perhaps we should ask them why they refrain from it.

Re: Face color changes

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 27 Dec 2004 23:57:39 -0500
> Cc: emacs-devel@gnu.org
> 
>     It suggests to replace "rosybrown" by "plum4" or "PaleVioletRed4", and
> 
> Does anyone want to argue that this change would make things worse?
> Does anyone want to argue for one or the other of those two choices?
> 
>     "orchid" (for font-lock-builtin-face) by "MediumOrchid3" or "DarkOrchid3".
> 
> Same two questions here.

I don't object to any of these changes, provided that they are done
for `(min-colors 88)' and `(min-colors 16)' branches.  The 8-color
terminals should be left alone, IMHO (they define different colors
anyway).

Re: Face color changes

[Richard Stallman]

    > In `custom-set-faces' it loses all conditions from the face
    > definition except the current one.  This means that saved faces are
    > the same on different environments.

    I think this is by design.  To make it behave differently, we need
    first to design the desired result.  What would you like it to do,
    exactly? modify only the definition that corresponds to the current
    background mode, number of colors, display type, etc., and leave the
    other definitions intact?

That seems right to me.

Re: Face color changes

[Juri Linkov]

"Eli Zaretskii" <eliz@gnu.org> writes:
>> In `custom-set-faces' it loses all conditions from the face
>> definition except the current one.  This means that saved faces are
>> the same on different environments.
>
> I think this is by design.  To make it behave differently, we need
> first to design the desired result.  What would you like it to do,
> exactly? modify only the definition that corresponds to the current
> background mode, number of colors, display type, etc., and leave the
> other definitions intact?

Exactly.

> In general, Customize does not support customizations that are
> portable across environments and/or platforms.  E.g., if you customize
> something on Windows, the result is not conditioned by the appropriate
> value of system-type.  Isn't the issue you raise similar?

No, the issue I raised concerns only conditions of the face
definition.  All conditions should be preserved with changes
made only in the condition for the current environment.
This would allow not only to keep conditions for other environments
in the saved face, but also to customize them independently
on different environments (most frequently switched of which are
light and dark backgrounds, where such improvement will be most useful).

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Face color changes

[Drew Adams]

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.

Re: Face color changes

[Alex Schroeder]

Juri Linkov <juri@jurta.org> writes:

> All conditions should be preserved with changes
> made only in the condition for the current environment.

This sounds a lot like overengineering to me.  Assume an innocent user
who takes his face definitions from one system to the next.  Depending
on what kind of system it is, his faces will either look like what he
customized them, or it will look like the default definitions for that
kind of system.

You seem to argue that the users' customization will not make sense on
the new system, if we add the necessary code.

I claim, however, that this "magic" will be harder to understand for
users that don't want to delve into customizations.

Which of the two points is more important?

Note that we don't have to worry about users that know a lot about
faces: They can for example M-x customize-face RET isearch RET 
Choose "State" and select "7 - select all display specs" -- they can
then do the customizations they require and save.

The only thing I think we might add is a check when saving if "just
showing current attributes" and other display specs exist.  I'm not
sure we need this, however.  If we wanted to teach new users about
display specs, we should just default to "show all display specs" --
and I don't think we want that.

In my opinion, we don't need to change anything.

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fifth law:
OOO  Never accept more work than you can handle in one night of hacking.

Re: Face color changes

[Alex Schroeder]

"Drew Adams" <drew.adams@oracle.com> writes:

> there are no doubt things that can be done to make it easier to
> create and change color schemes.

We have custom themes, but as far as I know, nobody has ever used them
for anything.  So either writing themes is difficult (having
maintained color-theme.el in the past, I don't think so), or custom
themes is not necessary (that's what I suspect) or too difficult to
use (maybe...).

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fifth law:
OOO  Never accept more work than you can handle in one night of hacking.

Re: Face color changes

[Robert J. Chassell]

   We have custom themes, but as far as I know, nobody has ever used
   them ....

I lose track of which themes are which and what I have already set in
my .emacs, so I do not use them.  If a theme kept a history of the
user's current set up -- everything -- and then of two or three new
ones, so the user could shift safely and try out things, perhaps
themes would be more often used.

Put another way, one column of the `visual user's theme interface'
would be what he has in a current .emacs.  Other columns could provide
defaults for light, medium, dark visual on X, similar on ttys of
various types, and several audio (e.g. use UK voices, French accent
for English... etc).

Themes should do more than color -- essentially, they simply write new
.emacs files, but with different names.  But as a beginning, a theme
might do just colors.

(I use `list-faces-display' and `customize' because I do not know
anything about colors and like to see them.  Then I put them into my
.emacs file in one of my `custom-set-faces' expressions.)

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Face color changes

[Robert J. Chassell]

   We have custom themes, but as far as I know, nobody has ever used
   them ....

As I said, I lose track of which themes are which.  It would be great
for a visual theme user interface to show various faces side by side
(obviously, you cannot show too many on an 80 char wide window).

Right now, in this instance of Emacs, `list-faces-display' shows 136
faces.  `emacs -Q' lists only 33.  136 are too many for me to
remember.  Even 33 are too many.  (I have no idea how to deal with
audio `faces', i.e., with `audio personalities'; perhaps the Emacspeak
people could help.)

Perhaps themes would be more often used if a theme kept a history of
the user's current set up -- everything -- and then of two or three
new ones, so the user could shift safely from one to another.

Put another way, one column of the `visual user's theme interface'
would be what he has in a current .emacs.  Other columns could provide
defaults for light, medium, dark visual on X, similar on ttys of
various types, and several audio (e.g. use UK voices, French accent
for English... etc).

Themes should do more than color -- essentially, a theme should write
a new .emacs file, but with a different name.  But as a beginning, a
theme might do just colors.

(For faces' customization, I use `list-faces-display' and `customize'
because I do not know anything about colors and like to see them.
Weights do not work on my main display.  Then I let customize "Save
for Future Sessions" change the last of the `custom-set-faces'
expressions in my .emacs file.)

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Face color changes

[Richard Stallman]

    This sounds a lot like overengineering to me.  Assume an innocent user
    who takes his face definitions from one system to the next.  Depending
    on what kind of system it is, his faces will either look like what he
    customized them, or it will look like the default definitions for that
    kind of system.

The alternative definitions for a face are condition by criteria
that make sense for that face--for instance, number of colors available
and color of background.

With the proposed change, if the user moves to a different system, he
will probably choose the same kind of background.  So unless the
display's capabilities are very different, he will get the same
alternative, and therefore the same customizations.  Usually.

But if he changes to a different kind of environment for which the
alternative he customized would not have been used at all, he will get
the default for that environment, which will probably be good.

That is why I believe this change is correct.

Re: Face color changes

[Miles Bader]

On Wed, Dec 29, 2004 at 04:26:14PM +0100, Alex Schroeder wrote:
> This sounds a lot like overengineering to me.  Assume an innocent user
> who takes his face definitions from one system to the next.  Depending
> on what kind of system it is, his faces will either look like what he
> customized them, or it will look like the default definitions for that
> kind of system.
...
> In my opinion, we don't need to change anything.

It seems that it's hard to do perfectly without using "show all display
specs" -- whether it  changes only the current spec, or overwrites
everything, it's probably going to screw up half the time.

However, I've definitely been burned by the current rather destructive
behavior.  I'll carefully customize several different specs (say tty and
default), and then _once_ I'll forget to use show-all-display-specs when
tweaking some minor detail, and -- whoops! -- all my other customizations
will be lost.

Perhaps a good method might be this: Default to show-all-display-specs _if_
the user has changed anything; if a face is still completely defaulted, just
show the current environment's spec case (as it does now).  That way, the
first time the user customizes a face, it will overwrite all specs for that
face with a single case, applying in all environments.  If he later wants to
change something, it will show all display specs, but that will be almost the
same as not doing so, because there will only be the single default entry due
to his previous customization.  If he later adds a new display-spec case
(which will be easy, as the "add case" widget will already be active), it
will then be displayed and shown for subsequent customizations, but that will
presumably not be too confusing, as all specs shown will have been added by
the user.

Since on average, such behavior would be almost the same as the current
behavior, this wouldn't be a drastic change either.

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: Face color changes

[Alex Schroeder]

Miles Bader <miles@gnu.org> writes:

> Perhaps a good method might be this: Default to show-all-display-specs _if_
> the user has changed anything

I think we should add "and the customizations don't specify "all
displays" (which is the default).

Thus, if a user customizes a face, and later customizes it again, the
buffer still looks the same.  All specs should only be the default if
the user has in fact customized any of them.

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fifth law:
OOO  Never accept more work than you can handle in one night of hacking.

Re: Face color changes

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> But if he changes to a different kind of environment for which the
> alternative he customized would not have been used at all, he will get
> the default for that environment, which will probably be good.

I argued that this will be confusing.  The user might ask: "Where did
my customizations disappear to?"  -- Since the user might not be aware
that the customizations would yield bad results on the new display,
this is a legitimate question.  Emacs will seem less "predictable"
(for lack of a better word to describe this aspect of usability).

Your reply did not address the issue.  You therefore assume this is no
problem?

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fifth law:
OOO  Never accept more work than you can handle in one night of hacking.

Re: Face color changes

[Richard Stallman]

    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.

I am not sure what "a couple of the colors swapped" means.  However,
it occurs to me that Customize, when showing a color, could offer
other ways to specify the color other than by name.  It could offer a
menu of color operations, or run a color-specification dialog, or
whatever seems useful.

Re: Face color changes

[Richard Stallman]

    Perhaps a good method might be this: Default to show-all-display-specs _if_
    the user has changed anything; if a face is still completely defaulted, just
    show the current environment's spec case (as it does now).  That way, the
    first time the user customizes a face, it will overwrite all specs for that
    face with a single case, applying in all environments.

That in itself is too drastic already.

Re: Face color changes

[Richard Stallman]

    I argued that this will be confusing.  The user might ask: "Where did
    my customizations disappear to?"  -- Since the user might not be aware
    that the customizations would yield bad results on the new display,
    this is a legitimate question.  Emacs will seem less "predictable"
    (for lack of a better word to describe this aspect of usability).

    Your reply did not address the issue.  You therefore assume this is no
    problem?

It is not a major problem.  It is normal that Emacs selects different
color values etc. on different displays.  This is just a special
case of that.

Re: Face color changes

[Miles Bader]

On Thu, 30 Dec 2004 11:43:54 -0500, Richard Stallman <rms@gnu.org> wrote:
>     Perhaps a good method might be this: Default to show-all-display-specs _if_
>     the user has changed anything; if a face is still completely defaulted, just
>     show the current environment's spec case (as it does now).  That way, the
>     first time the user customizes a face, it will overwrite all specs for that
>     face with a single case, applying in all environments.
> 
> That in itself is too drastic already.

Er, if by "that", you mean "overwrite all specs with a single case",
that's the _current_ behavior[1] (and has been the the behavior for as
long as I can remember[2]).  What my proposal would do would be to
preserve this behavior, but not screw over a user who has explicitly
customized multiple cases.

Whether "overwrite all" or "change just the current but preserve
others" is desirable or not grealy depends on the actual details of
the face and the user's particular customization, so it's probably not
possible to come up with a behavior that does the right thing all of
the time; all I'm suggesting to do is to at least make what happens
more visible.

[1] Well, actually the current behavior is slightly worse:  It deletes
all the cases except the currently active one, but _keeps_ the
"conditional" part of the current case, so I presume the face is
simply _disabled_ on other display types (I haven't explicitly tested
it however)...!

[2] It's not clear the current behavior is intentional though -- I
complained about it years ago, and Per's reply was "Oh I don't think
it's supposed to do that..."

-Miles

Re: Face color changes

[Richard Stallman]

    Er, if by "that", you mean "overwrite all specs with a single case",
    that's the _current_ behavior[1] (and has been the the behavior for as
    long as I can remember[2]).

Yes, but I think it is a drastic thing to do--to discard all the other
conditional alternatives that the user doesn't even know about.  The
user probably meant the customization to replace the behavior he saw.

Perhaps the customization buffer could show a button that says
"enable other alternatives for other kinds of displays", and it
would normally be "yes".  If the user turns it off, then the
customized behavior should be unconditional.  If the user leaves
it alone, then the customized behavior would be only for the
current alternative.

Re: Face color changes

[Kevin Rodgers]

Richard Stallman wrote:
 >     Er, if by "that", you mean "overwrite all specs with a single case",
 >     that's the _current_ behavior[1] (and has been the the behavior 
for as
 >     long as I can remember[2]).
 >
 > Yes, but I think it is a drastic thing to do--to discard all the other
 > conditional alternatives that the user doesn't even know about.  The
 > user probably meant the customization to replace the behavior he saw.

It's drastic, but it's basically the same thing that happens for
variables.  E.g. customizing this variable loses all of the logic
behind its value:

(defcustom foo
   (cond ((fboundp 'some-function) ...)
         ((featurep 'some-feature) ...)
         ((eq system-type 'some-system) ...)
         ((some-arbitrary-test) ...)
         (t ...)))

Since faces have conditional specs, should variables have specs (vs.
just lisp object values) as well?

-- 
Kevin Rodgers

Re: Face color changes

[Richard Stallman]

     > Yes, but I think it is a drastic thing to do--to discard all the other
     > conditional alternatives that the user doesn't even know about.  The
     > user probably meant the customization to replace the behavior he saw.

    It's drastic, but it's basically the same thing that happens for
    variables.

It is partly similar and partly different.  Variables don't have specs
with conditions, they just have initial value forms.  The fact that specs
represent the alternatives and their conditions in a declarative way
makes it natural not to discard them.

    Since faces have conditional specs, should variables have specs (vs.
    just lisp object values) as well?

This technique is useful for faces because (1) there is a limited set
of conditions that you might want to test and (2) users can plausibly
run in different backgrounds and terminals even on the same system.

It is clear we cannot usefully apply the specs technique to variables
generally.  Perhaps there are certain variables for which the technique
is applicable.

Re: Face color changes

[Juri Linkov]

Miles Bader <snogglethorpe@gmail.com> writes:
> [1] Well, actually the current behavior is slightly worse:  It deletes
> all the cases except the currently active one, but _keeps_ the
> "conditional" part of the current case, so I presume the face is
> simply _disabled_ on other display types (I haven't explicitly tested
> it however)...!

I have explicitly tested it, and what I see is illogical: even though it
keeps the condition for the current environment, other display types ignore
this condition, and the same customized value is used for all environments.

After further customization on different environments the saved condition
changes to the more reasonable value `default'.  This value would be
appropriate if the user's intention was to override all specs.  Otherwise,
it's better to keep all unmodified default conditions and add a new button
to the customization buffer to specify explicitly whether to keep all
conditions or override them with one value for all environments.

-- 
Juri Linkov
http://www.jurta.org/emacs/