all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#9402: list-colors-display
@ 2011-08-29 19:27 Juri Linkov
  2011-08-29 20:10 ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2011-08-29 19:27 UTC (permalink / raw)
  To: 9402

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'.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-29 19:27 bug#9402: list-colors-display Juri Linkov
@ 2011-08-29 20:10 ` Eli Zaretskii
  2011-08-29 21:17   ` Juri Linkov
  2011-08-30  7:44   ` Eli Zaretskii
  0 siblings, 2 replies; 36+ messages in thread
From: Eli Zaretskii @ 2011-08-29 20:10 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9402

> 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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-29 20:10 ` Eli Zaretskii
@ 2011-08-29 21:17   ` Juri Linkov
  2011-08-30  2:54     ` Eli Zaretskii
  2011-08-30  5:40     ` Jan D.
  2011-08-30  7:44   ` Eli Zaretskii
  1 sibling, 2 replies; 36+ messages in thread
From: Juri Linkov @ 2011-08-29 21:17 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9402

>> 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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-29 21:17   ` Juri Linkov
@ 2011-08-30  2:54     ` Eli Zaretskii
  2011-08-30  5:40     ` Jan D.
  1 sibling, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2011-08-30  2:54 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9402

> 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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-29 21:17   ` Juri Linkov
  2011-08-30  2:54     ` Eli Zaretskii
@ 2011-08-30  5:40     ` Jan D.
  2011-08-30  9:10       ` Juri Linkov
  1 sibling, 1 reply; 36+ messages in thread
From: Jan D. @ 2011-08-30  5:40 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9402

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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-29 20:10 ` Eli Zaretskii
  2011-08-29 21:17   ` Juri Linkov
@ 2011-08-30  7:44   ` Eli Zaretskii
  2011-08-30 17:46     ` Eli Zaretskii
  1 sibling, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2011-08-30  7:44 UTC (permalink / raw)
  To: juri; +Cc: 9402

> 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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-30  5:40     ` Jan D.
@ 2011-08-30  9:10       ` Juri Linkov
  2011-08-30 11:41         ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2011-08-30  9:10 UTC (permalink / raw)
  To: Jan D.; +Cc: 9402

> 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")





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-30  9:10       ` Juri Linkov
@ 2011-08-30 11:41         ` Eli Zaretskii
  2011-08-30 14:15           ` Andreas Schwab
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2011-08-30 11:41 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9402

> 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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-30 11:41         ` Eli Zaretskii
@ 2011-08-30 14:15           ` Andreas Schwab
  2011-08-30 17:57             ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Andreas Schwab @ 2011-08-30 14:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9402

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."





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-30  7:44   ` Eli Zaretskii
@ 2011-08-30 17:46     ` Eli Zaretskii
  2011-08-31  9:35       ` Juri Linkov
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2011-08-30 17:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9402

> 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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-30 14:15           ` Andreas Schwab
@ 2011-08-30 17:57             ` Eli Zaretskii
  0 siblings, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2011-08-30 17:57 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: 9402

> 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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-30 17:46     ` Eli Zaretskii
@ 2011-08-31  9:35       ` Juri Linkov
  2011-08-31 10:57         ` Eli Zaretskii
  2011-08-31 19:09         ` Jan Djärv
  0 siblings, 2 replies; 36+ messages in thread
From: Juri Linkov @ 2011-08-31  9:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9402

> 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).





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31  9:35       ` Juri Linkov
@ 2011-08-31 10:57         ` Eli Zaretskii
  2011-08-31 16:17           ` Chong Yidong
                             ` (2 more replies)
  2011-08-31 19:09         ` Jan Djärv
  1 sibling, 3 replies; 36+ messages in thread
From: Eli Zaretskii @ 2011-08-31 10:57 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9402

> 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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 10:57         ` Eli Zaretskii
@ 2011-08-31 16:17           ` Chong Yidong
  2011-08-31 19:02             ` Jan Djärv
  2011-08-31 16:27           ` Juri Linkov
  2011-08-31 19:11           ` Jan Djärv
  2 siblings, 1 reply; 36+ messages in thread
From: Chong Yidong @ 2011-08-31 16:17 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9402

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).





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 10:57         ` Eli Zaretskii
  2011-08-31 16:17           ` Chong Yidong
@ 2011-08-31 16:27           ` Juri Linkov
  2011-08-31 17:40             ` Eli Zaretskii
  2011-08-31 19:17             ` Jan Djärv
  2011-08-31 19:11           ` Jan Djärv
  2 siblings, 2 replies; 36+ messages in thread
From: Juri Linkov @ 2011-08-31 16:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9402

>> 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).





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 16:27           ` Juri Linkov
@ 2011-08-31 17:40             ` Eli Zaretskii
  2011-08-31 18:35               ` Juri Linkov
  2011-08-31 19:17             ` Jan Djärv
  1 sibling, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2011-08-31 17:40 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9402

> 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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 17:40             ` Eli Zaretskii
@ 2011-08-31 18:35               ` Juri Linkov
  2011-08-31 19:22                 ` Jan Djärv
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2011-08-31 18:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9402

> 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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 16:17           ` Chong Yidong
@ 2011-08-31 19:02             ` Jan Djärv
  2011-09-01  2:12               ` Chong Yidong
  0 siblings, 1 reply; 36+ messages in thread
From: Jan Djärv @ 2011-08-31 19:02 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 9402



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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31  9:35       ` Juri Linkov
  2011-08-31 10:57         ` Eli Zaretskii
@ 2011-08-31 19:09         ` Jan Djärv
  1 sibling, 0 replies; 36+ messages in thread
From: Jan Djärv @ 2011-08-31 19:09 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9402



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.






^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 10:57         ` Eli Zaretskii
  2011-08-31 16:17           ` Chong Yidong
  2011-08-31 16:27           ` Juri Linkov
@ 2011-08-31 19:11           ` Jan Djärv
  2011-08-31 20:00             ` Eli Zaretskii
  2 siblings, 1 reply; 36+ messages in thread
From: Jan Djärv @ 2011-08-31 19:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9402



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.






^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 16:27           ` Juri Linkov
  2011-08-31 17:40             ` Eli Zaretskii
@ 2011-08-31 19:17             ` Jan Djärv
  1 sibling, 0 replies; 36+ messages in thread
From: Jan Djärv @ 2011-08-31 19:17 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9402



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.








^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 18:35               ` Juri Linkov
@ 2011-08-31 19:22                 ` Jan Djärv
  2011-08-31 20:14                   ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Jan Djärv @ 2011-08-31 19:22 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9402



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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 19:11           ` Jan Djärv
@ 2011-08-31 20:00             ` Eli Zaretskii
  2011-08-31 20:10               ` Juri Linkov
  2011-08-31 21:06               ` Jan Djärv
  0 siblings, 2 replies; 36+ messages in thread
From: Eli Zaretskii @ 2011-08-31 20:00 UTC (permalink / raw)
  To: Jan Djärv; +Cc: 9402

> 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.






^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 20:00             ` Eli Zaretskii
@ 2011-08-31 20:10               ` Juri Linkov
  2011-09-01  2:50                 ` Eli Zaretskii
  2011-08-31 21:06               ` Jan Djärv
  1 sibling, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2011-08-31 20:10 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9402

> 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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 19:22                 ` Jan Djärv
@ 2011-08-31 20:14                   ` Eli Zaretskii
  2011-08-31 20:28                     ` Juri Linkov
                                       ` (2 more replies)
  0 siblings, 3 replies; 36+ messages in thread
From: Eli Zaretskii @ 2011-08-31 20:14 UTC (permalink / raw)
  To: Jan Djärv; +Cc: 9402

> 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.






^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 20:14                   ` Eli Zaretskii
@ 2011-08-31 20:28                     ` Juri Linkov
  2011-09-01  2:54                       ` Eli Zaretskii
  2011-08-31 21:07                     ` Jan Djärv
  2011-09-01  2:15                     ` Chong Yidong
  2 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2011-08-31 20:28 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9402

> 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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 20:00             ` Eli Zaretskii
  2011-08-31 20:10               ` Juri Linkov
@ 2011-08-31 21:06               ` Jan Djärv
  1 sibling, 0 replies; 36+ messages in thread
From: Jan Djärv @ 2011-08-31 21:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9402



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.






^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 20:14                   ` Eli Zaretskii
  2011-08-31 20:28                     ` Juri Linkov
@ 2011-08-31 21:07                     ` Jan Djärv
  2011-09-01  2:56                       ` Eli Zaretskii
  2011-09-01  2:15                     ` Chong Yidong
  2 siblings, 1 reply; 36+ messages in thread
From: Jan Djärv @ 2011-08-31 21:07 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9402



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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 19:02             ` Jan Djärv
@ 2011-09-01  2:12               ` Chong Yidong
  0 siblings, 0 replies; 36+ messages in thread
From: Chong Yidong @ 2011-09-01  2:12 UTC (permalink / raw)
  To: Jan Djärv; +Cc: 9402

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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 20:14                   ` Eli Zaretskii
  2011-08-31 20:28                     ` Juri Linkov
  2011-08-31 21:07                     ` Jan Djärv
@ 2011-09-01  2:15                     ` Chong Yidong
  2011-09-01  3:07                       ` Eli Zaretskii
  2 siblings, 1 reply; 36+ messages in thread
From: Chong Yidong @ 2011-09-01  2:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9402

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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 20:10               ` Juri Linkov
@ 2011-09-01  2:50                 ` Eli Zaretskii
  2011-09-01  8:36                   ` Juri Linkov
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2011-09-01  2:50 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9402

> 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.






^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 20:28                     ` Juri Linkov
@ 2011-09-01  2:54                       ` Eli Zaretskii
  0 siblings, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2011-09-01  2:54 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9402

> 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.






^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-08-31 21:07                     ` Jan Djärv
@ 2011-09-01  2:56                       ` Eli Zaretskii
  0 siblings, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2011-09-01  2:56 UTC (permalink / raw)
  To: Jan Djärv; +Cc: 9402

> 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.







^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-09-01  2:15                     ` Chong Yidong
@ 2011-09-01  3:07                       ` Eli Zaretskii
  0 siblings, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2011-09-01  3:07 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 9402

> 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.






^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-09-01  2:50                 ` Eli Zaretskii
@ 2011-09-01  8:36                   ` Juri Linkov
  2011-09-01 10:06                     ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Juri Linkov @ 2011-09-01  8:36 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9402

> 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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#9402: list-colors-display
  2011-09-01  8:36                   ` Juri Linkov
@ 2011-09-01 10:06                     ` Eli Zaretskii
  0 siblings, 0 replies; 36+ messages in thread
From: Eli Zaretskii @ 2011-09-01 10:06 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 9402-done

> 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.





^ permalink raw reply	[flat|nested] 36+ messages in thread

end of thread, other threads:[~2011-09-01 10:06 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-08-29 19:27 bug#9402: list-colors-display Juri Linkov
2011-08-29 20:10 ` Eli Zaretskii
2011-08-29 21:17   ` Juri Linkov
2011-08-30  2:54     ` Eli Zaretskii
2011-08-30  5:40     ` Jan D.
2011-08-30  9:10       ` Juri Linkov
2011-08-30 11:41         ` Eli Zaretskii
2011-08-30 14:15           ` Andreas Schwab
2011-08-30 17:57             ` Eli Zaretskii
2011-08-30  7:44   ` Eli Zaretskii
2011-08-30 17:46     ` Eli Zaretskii
2011-08-31  9:35       ` Juri Linkov
2011-08-31 10:57         ` Eli Zaretskii
2011-08-31 16:17           ` Chong Yidong
2011-08-31 19:02             ` Jan Djärv
2011-09-01  2:12               ` Chong Yidong
2011-08-31 16:27           ` Juri Linkov
2011-08-31 17:40             ` Eli Zaretskii
2011-08-31 18:35               ` Juri Linkov
2011-08-31 19:22                 ` Jan Djärv
2011-08-31 20:14                   ` Eli Zaretskii
2011-08-31 20:28                     ` Juri Linkov
2011-09-01  2:54                       ` Eli Zaretskii
2011-08-31 21:07                     ` Jan Djärv
2011-09-01  2:56                       ` Eli Zaretskii
2011-09-01  2:15                     ` Chong Yidong
2011-09-01  3:07                       ` Eli Zaretskii
2011-08-31 19:17             ` Jan Djärv
2011-08-31 19:11           ` Jan Djärv
2011-08-31 20:00             ` Eli Zaretskii
2011-08-31 20:10               ` Juri Linkov
2011-09-01  2:50                 ` Eli Zaretskii
2011-09-01  8:36                   ` Juri Linkov
2011-09-01 10:06                     ` Eli Zaretskii
2011-08-31 21:06               ` Jan Djärv
2011-08-31 19:09         ` Jan Djärv

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.