bug#9402: list-colors-display

bug#9402: list-colors-display

[Juri Linkov]

Two problems related to `list-colors-display':

1. On a tty, running `M-x list-colors-display RET' displays
truncated hex color values like:              red    #cd000$
where $ is displayed at the end of the partial line.

To display the complete line this could be fixed by incrementing
`align-to' from 9 to 10 in `list-colors-print'.  But after that
when running it on X two extra spaces are displayed at the end
of these lines.

Maybe the bug is somewhere deeper in the display engine
that aligns differently on a tty and X?

2. New faces `gtk_selection_fg_color' and `gtk_selection_bg_color'
now are available for using on GTK but they are not listed in
`list-colors-display', and they can't be selected and completed in
`customize-face'.

There are more colors that are valid for using but hidden from users
such as e.g. on a tty: `unspecified-fg', `unspecified-bg'.

bug#9402: list-colors-display

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Mon, 29 Aug 2011 22:27:50 +0300
> 
> 1. On a tty, running `M-x list-colors-display RET' displays
> truncated hex color values like:              red    #cd000$
> where $ is displayed at the end of the partial line.
> 
> To display the complete line this could be fixed by incrementing
> `align-to' from 9 to 10 in `list-colors-print'.  But after that
> when running it on X two extra spaces are displayed at the end
> of these lines.
> 
> Maybe the bug is somewhere deeper in the display engine
> that aligns differently on a tty and X?

It aligns differently, but the result should be identical.  I will
take a look.

> 2. New faces `gtk_selection_fg_color' and `gtk_selection_bg_color'
> now are available for using on GTK but they are not listed in
> `list-colors-display', and they can't be selected and completed in
> `customize-face'.

Did this ever work?  Emacs always had platform-specific colors besides
those in rgb.txt, I don't think this is something new.

> There are more colors that are valid for using but hidden from users
> such as e.g. on a tty: `unspecified-fg', `unspecified-bg'.

They are meaningless and cannot be set by Emacs.  IOW, they are
"read-only", as far as Emacs is concerned.  Exposing them to users
would be confusing.

bug#9402: list-colors-display

[Juri Linkov]

>> 2. New faces `gtk_selection_fg_color' and `gtk_selection_bg_color'
>> now are available for using on GTK but they are not listed in
>> `list-colors-display', and they can't be selected and completed in
>> `customize-face'.
>
> Did this ever work?  Emacs always had platform-specific colors besides
> those in rgb.txt, I don't think this is something new.

Yes, it never worked.

>> There are more colors that are valid for using but hidden from users
>> such as e.g. on a tty: `unspecified-fg', `unspecified-bg'.
>
> They are meaningless and cannot be set by Emacs.  IOW, they are
> "read-only", as far as Emacs is concerned.  Exposing them to users
> would be confusing.

All colors are "read-only" for users in the sense that users can't
change them.  But platform-specific colors are not different from other
colors in the sense that they are used in face customization.

IOW, when the user types `M-x customize-face RET region RET'
then s?he sees the color name "gtk_selection_fg_color".
Then the user might change it to some other color, but after that
it's difficult to restore the original default color name,
because the user don't remember this color name literally
and can't select it using completion or the "Choose" button
that lists all color names.

bug#9402: list-colors-display

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: 9402@debbugs.gnu.org
> Date: Tue, 30 Aug 2011 00:17:42 +0300
> 
> >> There are more colors that are valid for using but hidden from users
> >> such as e.g. on a tty: `unspecified-fg', `unspecified-bg'.
> >
> > They are meaningless and cannot be set by Emacs.  IOW, they are
> > "read-only", as far as Emacs is concerned.  Exposing them to users
> > would be confusing.
> 
> All colors are "read-only" for users in the sense that users can't
> change them.  But platform-specific colors are not different from other
> colors in the sense that they are used in face customization.

Sorry, I was talking only about unspecified-bg and unspecified-fg.
Emacs simply has no way of requesting these colors, it uses these
names for the original TTY color whose foreground and background are
unknown.

bug#9402: list-colors-display

[Jan D.]

Hello.

Juri Linkov skrev 2011-08-29 23:17:

>
> IOW, when the user types `M-x customize-face RET region RET'
> then s?he sees the color name "gtk_selection_fg_color".
> Then the user might change it to some other color, but after that
> it's difficult to restore the original default color name,
> because the user don't remember this color name literally
> and can't select it using completion or the "Choose" button
> that lists all color names.
>
>

That is on purpose.  Say a user customizes a face to use 
gtk_selection_fg_color and saves it.  He then starts an Emacs compiled 
without Gtk+.  What color shall Emacs use then?

	Jan D.

bug#9402: list-colors-display

[Juri Linkov]

> That is on purpose.  Say a user customizes a face to use
> gtk_selection_fg_color and saves it.  He then starts an Emacs compiled
> without Gtk+.  What color shall Emacs use then?

Exactly the same problem exists for all other conditional
face customizations.

What if a user customizes a face on X for min-colors 88 and starts Emacs on
a tty with 8 colors?  Or customizes a face to "color-255" on xterm-256color
and starts Emacs on X?  Or customizes a face for light background and
starts Emacs on dark background?  Or customizes a face for bold and starts
Emacs where bold is not supported?  And so on.

Of course, graceful degradation to some closer colors could help,
but the result would not be what the user has customized.

To avoid these problems, customize-face should retain the conditional
part of the face definition when saving the modified face.

So e.g. after customizing `region' to some other colors:

    (((class color) (min-colors 88) (background light) (type gtk))
     :foreground "white"
     :background "black")

And after restoring the original default colors the condition
will remain intact in `custom-set-faces':

    (((class color) (min-colors 88) (background light) (type gtk))
     :foreground "gtk_selection_fg_color"
     :background "gtk_selection_bg_color")

bug#9402: list-colors-display

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  9402@debbugs.gnu.org
> Date: Tue, 30 Aug 2011 12:10:51 +0300
> 
> What if a user customizes a face on X for min-colors 88 and starts Emacs on
> a tty with 8 colors?

TTY is not a problem: each color goes through color approximation (see
tty-colors.el), so Emacs will choose some available color whose RGB
values are the closest to the one specified.

> Or customizes a face to "color-255" on xterm-256color
> and starts Emacs on X?  Or customizes a face for light background and
> starts Emacs on dark background?  Or customizes a face for bold and starts
> Emacs where bold is not supported?  And so on.

The answer is clear: unsupported attributes and colors are ignored,
the color approximation for TTY mentioned above being the only
exception.

> Of course, graceful degradation to some closer colors could help,
> but the result would not be what the user has customized.

What else can Emacs possibly do?

> To avoid these problems, customize-face should retain the conditional
> part of the face definition when saving the modified face.

This doesn't work in general because most faces don't provide values
for every possible level of support.

>     (((class color) (min-colors 88) (background light) (type gtk))
>      :foreground "gtk_selection_fg_color"
>      :background "gtk_selection_bg_color")

Aha, and then you run this on an older GTK version where
gtk_selection_bg_color isn't supported, then what?

The only way out of this mess that has some future is to expand the
color approximation we have for TTY to all the other display types.
That will at least work as reliably as humanly possible.  Nothing else
will ever work reliably.

bug#9402: list-colors-display

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Aha, and then you run this on an older GTK version where
> gtk_selection_bg_color isn't supported, then what?

You cannot expect forward compatiblity in general.  If you downgrade
then you have to cope with possibly missing features.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#9402: list-colors-display

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Juri Linkov <juri@jurta.org>,  9402@debbugs.gnu.org
> Date: Tue, 30 Aug 2011 16:15:48 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Aha, and then you run this on an older GTK version where
> > gtk_selection_bg_color isn't supported, then what?
> 
> You cannot expect forward compatiblity in general.  If you downgrade
> then you have to cope with possibly missing features.

I'm not looking for compatibility, I'm looking for a way to have such
a face stand out in _some_ color.  Otherwise, it will be displayed
indistinguishable from the default face.

bug#9402: list-colors-display

[Eli Zaretskii]

> Date: Mon, 29 Aug 2011 23:10:01 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 9402@debbugs.gnu.org
> 
> > From: Juri Linkov <juri@jurta.org>
> > Date: Mon, 29 Aug 2011 22:27:50 +0300
> > 
> > 1. On a tty, running `M-x list-colors-display RET' displays
> > truncated hex color values like:              red    #cd000$
> > where $ is displayed at the end of the partial line.
> > 
> > To display the complete line this could be fixed by incrementing
> > `align-to' from 9 to 10 in `list-colors-print'.  But after that
> > when running it on X two extra spaces are displayed at the end
> > of these lines.
> > 
> > Maybe the bug is somewhere deeper in the display engine
> > that aligns differently on a tty and X?
> 
> It aligns differently, but the result should be identical.  I will
> take a look.

I see the problem: the calculation of the width of the stretch of
white space is subtly different in the TTY and GUI versions of the
code.  It all comes from The Mother Of All Evil: having two separate
versions of code where in fact the TTY version is a proper subset of
the GUI one.

I will merge both versions into one later today, and that should fix
the bug.

bug#9402: list-colors-display

[Eli Zaretskii]

> Date: Tue, 30 Aug 2011 03:44:37 -0400
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 9402@debbugs.gnu.org
> 
> I will merge both versions into one later today, and that should fix
> the bug.

Done in revision 105619 on the trunk.

bug#9402: list-colors-display

[Juri Linkov]

> Done in revision 105619 on the trunk.

Thank you.  I confirm that it's fixed now.

As for platform-specific colors, what I meant is implementing exactly
the same handling of colors as currently is already implemented in Emacs
on Windows where `M-x list-colors-display' lists platform-specific colors
at the end of the color list: `SystemBackground', `SystemWindow',
`SystemWindowText' and all other system colors, and the user can select
system colors in `customize-face' via completion or the "Choose" button
that includes all platform-specific colors.

Another question is why the face definition of `region' has
platform-specific colors for GTK and NS, but not for Windows.
In Emacs on Windows two system colors are available exactly
for that purpose.  Their names are `SystemHilight' (background)
and `SystemHilightText' (foreground).

bug#9402: list-colors-display

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: 9402@debbugs.gnu.org
> Date: Wed, 31 Aug 2011 12:35:18 +0300
> 
> > Done in revision 105619 on the trunk.
> 
> Thank you.  I confirm that it's fixed now.

Thanks for testing.

> Another question is why the face definition of `region' has
> platform-specific colors for GTK and NS, but not for Windows.

I would actually turn the table and ask why the heck do we have
system-specific defaults for GTK and NS.  I thought Emacs was supposed
to behave the same on all platforms, except where it's impossible.

bug#9402: list-colors-display

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> Another question is why the face definition of `region' has
>> platform-specific colors for GTK and NS, but not for Windows.
>
> I would actually turn the table and ask why the heck do we have
> system-specific defaults for GTK and NS.  I thought Emacs was supposed
> to behave the same on all platforms, except where it's impossible.

In this case, the behavior is "use the system default" ;-)

FWIW, I am also ambivalent about this feature.  The system selection
color can clash with the default Emacs foreground/background color,
unless those colors are also taken from the system (which AFAIK it is
not).

bug#9402: list-colors-display

[Jan Djärv]

Chong Yidong skrev 2011-08-31 18:17:
> Eli Zaretskii<eliz@gnu.org>  writes:
>
>>> Another question is why the face definition of `region' has
>>> platform-specific colors for GTK and NS, but not for Windows.
>>
>> I would actually turn the table and ask why the heck do we have
>> system-specific defaults for GTK and NS.  I thought Emacs was supposed
>> to behave the same on all platforms, except where it's impossible.
>
> In this case, the behavior is "use the system default" ;-)
>
> FWIW, I am also ambivalent about this feature.  The system selection
> color can clash with the default Emacs foreground/background color,
> unless those colors are also taken from the system (which AFAIK it is
> not).
>
>

Well, Emacs does not try to avoid that either.  On a non-gtk, but X Emacs do
emacs -Q -bg lightgoldenrod2

and then mark some text.  The region face will be invisible.

	Jan D.

bug#9402: list-colors-display

[Chong Yidong]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Well, Emacs does not try to avoid that either.  On a non-gtk, but X
> Emacs do emacs -Q -bg lightgoldenrod2
>
> and then mark some text.  The region face will be invisible.

The two cases differ.  If the user changes a color via Emacs, she should
be responsible for color clashes.  But if the user changes system colors
outside Emacs (e.g. via a desktop theme), and that leads to a color
clash in Emacs because Emacs only looks at the highlight color, that can
be considered an Emacs problem.

I don't think this is a huge problem, but it's certainly worth looking
into at some point.

bug#9402: list-colors-display

[Juri Linkov]

>> Another question is why the face definition of `region' has
>> platform-specific colors for GTK and NS, but not for Windows.
>
> I would actually turn the table and ask why the heck do we have
> system-specific defaults for GTK and NS.  I thought Emacs was supposed
> to behave the same on all platforms, except where it's impossible.

Emacs should respect the user settings even if they are made on
system level.  Emacs already respects the user's choice of
system-specific colors on a tty (with `unspecified-fg' and
`unspecified-bg') and some other system-specific customizations.

I don't remember the goal of trying to look the same on all platforms
and indeed Emacs already doesn't look the same on different platforms:
there are different scroll bars, frame decorations, fonts, icons, etc.
So Emacs should adapt to the platform defaults as much as possible.

What is still missing is using just few remaining colors for few platforms.
(And another thing is that the GTK version doesn't respect the user's GTK
settings for the blinking cursor, whereas the Windows version does).

bug#9402: list-colors-display

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: 9402@debbugs.gnu.org
> Date: Wed, 31 Aug 2011 19:27:45 +0300
> 
> >> Another question is why the face definition of `region' has
> >> platform-specific colors for GTK and NS, but not for Windows.
> >
> > I would actually turn the table and ask why the heck do we have
> > system-specific defaults for GTK and NS.  I thought Emacs was supposed
> > to behave the same on all platforms, except where it's impossible.
> 
> Emacs should respect the user settings even if they are made on
> system level.

How many users actually change these system-level settings from their
defaults?  My guess is zero.

> Emacs already respects the user's choice of system-specific colors
> on a tty (with `unspecified-fg' and `unspecified-bg') and some other
> system-specific customizations.

You have it backwards.  The _only_ reason Emacs does that is on a tty
is that many text terminals cannot be queried about their colors.
When Emacs can do that, it sets its own default colors.

> I don't remember the goal of trying to look the same on all platforms
> and indeed Emacs already doesn't look the same on different platforms:
> there are different scroll bars, frame decorations, fonts, icons, etc.

These are specific to GUI toolkits and/or window managers.  IOW,
something that is out of Emacs control.  Colors that Emacs uses for
non-default faces do not fall under the same category.

> So Emacs should adapt to the platform defaults as much as possible.

Obviously, I disagree.  Emacs should have the same defaults on all
platforms, as much as possible.  People such as myself who use Emacs
on multiple platforms become very confused when the colors they expect
don't show.

bug#9402: list-colors-display

[Juri Linkov]

> How many users actually change these system-level settings from their
> defaults?  My guess is zero.

Many users switch pre-defined system themes (because this is very easy to do).
And when the user likes the default system-level settings, it's the user's
preference after all that should be respected.

>> So Emacs should adapt to the platform defaults as much as possible.
>
> Obviously, I disagree.  Emacs should have the same defaults on all
> platforms, as much as possible.  People such as myself who use Emacs
> on multiple platforms become very confused when the colors they expect
> don't show.

For users that use more applications beside Emacs on one platform
it's annoying when Emacs doesn't follow common system-wide look and feel.

I think there are more users that use many applications on one platform
and want all of them look the same than the number of users who use
just Emacs and switch platforms frequently.

bug#9402: list-colors-display

[Jan Djärv]

Juri Linkov skrev 2011-08-31 20:35:

>>
>> Obviously, I disagree.  Emacs should have the same defaults on all
>> platforms, as much as possible.  People such as myself who use Emacs
>> on multiple platforms become very confused when the colors they expect
>> don't show.
>
> For users that use more applications beside Emacs on one platform
> it's annoying when Emacs doesn't follow common system-wide look and feel.
>
> I think there are more users that use many applications on one platform
> and want all of them look the same than the number of users who use
> just Emacs and switch platforms frequently.
>
>

I use Emacs on multiple platforms and I do want Emacs to look like other 
applications on respective platform.  But I think you are right about the 
majority.

	Jan D.

bug#9402: list-colors-display

[Eli Zaretskii]

> Date: Wed, 31 Aug 2011 21:22:02 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: Eli Zaretskii <eliz@gnu.org>, 9402@debbugs.gnu.org
> 
> > For users that use more applications beside Emacs on one platform
> > it's annoying when Emacs doesn't follow common system-wide look and feel.
> >
> > I think there are more users that use many applications on one platform
> > and want all of them look the same than the number of users who use
> > just Emacs and switch platforms frequently.
> >
> >
> 
> I use Emacs on multiple platforms and I do want Emacs to look like other 
> applications on respective platform.  But I think you are right about the 
> majority.

I always thought that there are some principles in Emacs UI design
that are not subject to the majority tyranny.  I guess that's no
longer true.

bug#9402: list-colors-display

[Juri Linkov]

> I always thought that there are some principles in Emacs UI design
> that are not subject to the majority tyranny.  I guess that's no
> longer true.

I think the only thing where the opinion of the majority should
be decisive is the default values.  Everything should be
customizable for the minority.

bug#9402: list-colors-display

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: Jan Djärv <jan.h.d@swipnet.se>,  9402@debbugs.gnu.org
> Date: Wed, 31 Aug 2011 23:28:35 +0300
> 
> > I always thought that there are some principles in Emacs UI design
> > that are not subject to the majority tyranny.  I guess that's no
> > longer true.
> 
> I think the only thing where the opinion of the majority should
> be decisive is the default values.  Everything should be
> customizable for the minority.

I was talking about the principle of similar behavior.

bug#9402: list-colors-display

[Jan Djärv]

Eli Zaretskii skrev 2011-08-31 22:14:
>> Date: Wed, 31 Aug 2011 21:22:02 +0200
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> CC: Eli Zaretskii<eliz@gnu.org>, 9402@debbugs.gnu.org
>>
>>> For users that use more applications beside Emacs on one platform
>>> it's annoying when Emacs doesn't follow common system-wide look and feel.
>>>
>>> I think there are more users that use many applications on one platform
>>> and want all of them look the same than the number of users who use
>>> just Emacs and switch platforms frequently.
>>>
>>>
>>
>> I use Emacs on multiple platforms and I do want Emacs to look like other
>> applications on respective platform.  But I think you are right about the
>> majority.
>
> I always thought that there are some principles in Emacs UI design
> that are not subject to the majority tyranny.  I guess that's no
> longer true.

Isn't the only reson for a windows port the fact that so many use windows?

	Jan D.

bug#9402: list-colors-display

[Eli Zaretskii]

> Date: Wed, 31 Aug 2011 23:07:44 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: juri@jurta.org, 9402@debbugs.gnu.org
> 
> > I always thought that there are some principles in Emacs UI design
> > that are not subject to the majority tyranny.  I guess that's no
> > longer true.
> 
> Isn't the only reson for a windows port the fact that so many use windows?

And that adversely affects Unix users how exactly?  It doesn't, so
there's no majority tyranny here.

bug#9402: list-colors-display

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> I use Emacs on multiple platforms and I do want Emacs to look like
>> other applications on respective platform.  But I think you are right
>> about the majority.
>
> I always thought that there are some principles in Emacs UI design
> that are not subject to the majority tyranny.  I guess that's no
> longer true.

I think it is an exaggeration to refer to altering the region's
background color as a case of succumbing to tyranny.

bug#9402: list-colors-display

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Jan Djärv <jan.h.d@swipnet.se>, juri@jurta.org,
>         9402@debbugs.gnu.org
> Date: Wed, 31 Aug 2011 22:15:03 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I use Emacs on multiple platforms and I do want Emacs to look like
> >> other applications on respective platform.  But I think you are right
> >> about the majority.
> >
> > I always thought that there are some principles in Emacs UI design
> > that are not subject to the majority tyranny.  I guess that's no
> > longer true.
> 
> I think it is an exaggeration to refer to altering the region's
> background color as a case of succumbing to tyranny.

I actually meant that issues of principles such as
platform-independent behavior should not be decided by majority.

bug#9402: list-colors-display

[Jan Djärv]

Juri Linkov skrev 2011-08-31 18:27:
>>> Another question is why the face definition of `region' has
>>> platform-specific colors for GTK and NS, but not for Windows.
>>
>> I would actually turn the table and ask why the heck do we have
>> system-specific defaults for GTK and NS.  I thought Emacs was supposed
>> to behave the same on all platforms, except where it's impossible.
>
> Emacs should respect the user settings even if they are made on
> system level.  Emacs already respects the user's choice of
> system-specific colors on a tty (with `unspecified-fg' and
> `unspecified-bg') and some other system-specific customizations.
>
> I don't remember the goal of trying to look the same on all platforms
> and indeed Emacs already doesn't look the same on different platforms:
> there are different scroll bars, frame decorations, fonts, icons, etc.
> So Emacs should adapt to the platform defaults as much as possible.
>
> What is still missing is using just few remaining colors for few platforms.
> (And another thing is that the GTK version doesn't respect the user's GTK
> settings for the blinking cursor, whereas the Windows version does).

Very few people customize blink cursor, double click time, icon sizes, tooltip 
timeout and the other GTK settings (most which actually are GConf and/or 
GSettings, not GTK settings).  I suspect most people don't even notice that 
double click time is different in Emacs and Gtk+ applications.

So it hasn't been a high priority to follow all external settings.  Just the 
most visible ones (font, dpi, and highlight) have been done.  Patches welcome 
of course.

	Jan D.

bug#9402: list-colors-display

[Jan Djärv]

Eli Zaretskii skrev 2011-08-31 12:57:
>> From: Juri Linkov<juri@jurta.org>
>> Cc: 9402@debbugs.gnu.org
>> Date: Wed, 31 Aug 2011 12:35:18 +0300
>>
>>> Done in revision 105619 on the trunk.
>>
>> Thank you.  I confirm that it's fixed now.
>
> Thanks for testing.
>
>> Another question is why the face definition of `region' has
>> platform-specific colors for GTK and NS, but not for Windows.
>
> I would actually turn the table and ask why the heck do we have
> system-specific defaults for GTK and NS.  I thought Emacs was supposed
> to behave the same on all platforms, except where it's impossible.

The GUI is far from identical on all platforms.  This is just a GUI thing, the 
behaviour is the same.  For better integration with the desktop it is 
desirable to have the default highlight match other applications.

	Jan D.

bug#9402: list-colors-display

[Eli Zaretskii]

> Date: Wed, 31 Aug 2011 21:11:40 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: Juri Linkov <juri@jurta.org>, 9402@debbugs.gnu.org
> 
> > I would actually turn the table and ask why the heck do we have
> > system-specific defaults for GTK and NS.  I thought Emacs was supposed
> > to behave the same on all platforms, except where it's impossible.
> 
> The GUI is far from identical on all platforms.

??? What do you mean by that?  The widgets may look somewhat
differently, but the behavior is the same and the menus present the
same choices.

> This is just a GUI thing, the behaviour is the same.

Colors are significant, because humans tend to associate meaning to
each color.  Messing them up confuses those who have certain default
colors hard-wired into their brains.

IOW, it's not "just a GUI thing", it's a very important part of Emacs
look-and-feel.

> For better integration with the desktop it is desirable to have the
> default highlight match other applications.

Obviously, I couldn't disagree more, when colors are involved.

bug#9402: list-colors-display

[Juri Linkov]

> Colors are significant, because humans tend to associate meaning to
> each color.  Messing them up confuses those who have certain default
> colors hard-wired into their brains.

You can't have the same colors even on one platform now.
When you run Emacs on a tty you get an absolutely different set of colors
than when you run Emacs on X.  When you run Emacs on dark background,
you get different colors than on light background, and so on.

So an attempt to bring all colors to some unique set is futile.
It would be better to do what most users want to see by default.

bug#9402: list-colors-display

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: Jan Djärv <jan.h.d@swipnet.se>,  9402@debbugs.gnu.org
> Date: Wed, 31 Aug 2011 23:10:20 +0300
> 
> You can't have the same colors even on one platform now.
> When you run Emacs on a tty you get an absolutely different set of colors
> than when you run Emacs on X.

It's not absolutely different.  It approximates the X colors where
that is possible.  I did say the behavior should be the same "as much
as possible", didn't I?

> When you run Emacs on dark background, you get different colors
> than on light background, and so on.

Aha, and what would your "system defaults" do when the background mode
changes?  The Windows "default" region color is a very deep blue
background, which will be almost invisible on a dark background.

> So an attempt to bring all colors to some unique set is futile.

Yeah, right.

bug#9402: list-colors-display

[Juri Linkov]

> Aha, and what would your "system defaults" do when the background mode
> changes?  The Windows "default" region color is a very deep blue
> background, which will be almost invisible on a dark background.

Exactly the same deep blue background is currently used by default
on a dark background in the face definition:

  (defface region
    '((((class color) (min-colors 88) (background dark))
       :background "blue3")

:-P

bug#9402: list-colors-display

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: jan.h.d@swipnet.se,  9402@debbugs.gnu.org
> Date: Thu, 01 Sep 2011 11:36:44 +0300
> 
> > Aha, and what would your "system defaults" do when the background mode
> > changes?  The Windows "default" region color is a very deep blue
> > background, which will be almost invisible on a dark background.
> 
> Exactly the same deep blue background is currently used by default
> on a dark background in the face definition:
> 
>   (defface region
>     '((((class color) (min-colors 88) (background dark))
>        :background "blue3")

No, they are different.  Look at the RGB values, if you don't see that
by just looking at the colors.  Blue3 looks sufficiently different
from black on my display.

Anyway, time to close this bug report.

bug#9402: list-colors-display

[Jan Djärv]

Eli Zaretskii skrev 2011-08-31 22:00:

>
> Colors are significant, because humans tend to associate meaning to
> each color.  Messing them up confuses those who have certain default
> colors hard-wired into their brains.
>

I agree, but the "messing up" is done by Emacs when not using system colors.

	Jan D.

bug#9402: list-colors-display

[Jan Djärv]

Juri Linkov skrev 2011-08-31 11:35:
>> Done in revision 105619 on the trunk.
>
> Thank you.  I confirm that it's fixed now.
>
> As for platform-specific colors, what I meant is implementing exactly
> the same handling of colors as currently is already implemented in Emacs
> on Windows where `M-x list-colors-display' lists platform-specific colors
> at the end of the color list: `SystemBackground', `SystemWindow',
> `SystemWindowText' and all other system colors, and the user can select
> system colors in `customize-face' via completion or the "Choose" button
> that includes all platform-specific colors.
>
> Another question is why the face definition of `region' has
> platform-specific colors for GTK and NS, but not for Windows.
> In Emacs on Windows two system colors are available exactly
> for that purpose.  Their names are `SystemHilight' (background)
> and `SystemHilightText' (foreground).
>

As there is no mention of SystemHilight in the Emacs sources (well, except for 
one comment), I assume that W32 itself understands these colors.  There is no 
equivalent on NS/Gtk+, hence it was invented.

It is a trivial matter to change the names so they are the same on the various 
platforms.

	Jan D.