bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Van L]

Hello,

This is a suggestion for a reasonable default fore/background color combo.

Run: 
  emacs -Q

See:
  Customize Group: Hi Lock Faces
  Hi Green B

I see:
  foreground:green1 
  background:white (which I guess is a received setting from somewhere else)

For me, this is a very difficult combo to see. 

I’d like to suggest the default to be for `Hi Green B':

  foreground:darkcyan

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

> I see:
>   foreground:green1
>   background:white (which I guess is a received setting from somewhere else)
>
> For me, this is a very difficult combo to see.

I see the same - it is difficult to read.

> I’d like to suggest the default to be for `Hi Green B':
>
>   foreground:darkcyan

But darkcyan is not green.  Maybe better to create a new face `Hi Cyan B'
for darkcyan, and use darkgreen for `Hi Green B'?

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Van L]

> On 16 Nov 2018, at 08:25, Juri Linkov <juri@linkov.net> wrote:
> 
>> I see:
>>  foreground:green1
>>  background:white (which I guess is a received setting from somewhere else)
>> 
>> For me, this is a very difficult combo to see.
> 
> I see the same - it is difficult to read.

I don’t have red color blindness but suspect `Hi Red B’ would be difficult for a percentage of people.

>> I’d like to suggest the default to be for `Hi Green B':
>> 
>>  foreground:darkcyan
> 
> But darkcyan is not green.  Maybe better to create a new face `Hi Cyan B'
> for darkcyan, and use darkgreen for `Hi Green B'?

The ROYGBIV mnemonic for the colors of the rainbow could be a theme for the list to cycle through in `Hi Lock Faces’.

Darkgreen is an improvement on green1 for `Hi Green B’.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

>>> I see:
>>>  foreground:green1
>>>  background:white (which I guess is a received setting from somewhere else)
>>>
>>> For me, this is a very difficult combo to see.
>>
>> I see the same - it is difficult to read.
>
> I don’t have red color blindness but suspect `Hi Red B’ would be
> difficult for a percentage of people.

Yes, the current shade of red is too glaring.

>>> I’d like to suggest the default to be for `Hi Green B':
>>>
>>>  foreground:darkcyan
>>
>> But darkcyan is not green.  Maybe better to create a new face `Hi Cyan B'
>> for darkcyan, and use darkgreen for `Hi Green B'?
>
> The ROYGBIV mnemonic for the colors of the rainbow could be a theme
> for the list to cycle through in `Hi Lock Faces’.

Good idea.  A rainbow for background colors and a rainbow for foreground
colors, totally 14 colors, twice more colors instead of current 4 background
and 3 foreground colors.

> Darkgreen is an improvement on green1 for `Hi Green B’.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Van L]

>> I don’t have red color blindness but suspect `Hi Red B’ would be
>> difficult for a percentage of people.
> 
> Yes, the current shade of red is too glaring.

#ee2d3d is less glaring. 

For red color blind people a contrast to that as fore/background will trim down the number of people unable to see.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

>>> I don’t have red color blindness but suspect `Hi Red B’ would be
>>> difficult for a percentage of people.
>>
>> Yes, the current shade of red is too glaring.
>
> #ee2d3d is less glaring.

I see that the closest color for this is named "brown2".
It's not required to always use colors with names,
but in this case "brown2" is very close.  Another close
candidates are "red2" and "firebrick2".

Then for hi-green we could use "green3".

Regarding your idea of using rainbow colors, the problem
is that on TTY there are only these colors:

red, green, yellow, blue, magenta, cyan

hi-blue face uses cyan color, not blue, and
hi-pink face uses magenta color, not red.

Since hi-yellow uses yellow, and hi-green uses green already,
unfortunately there are no other colors available on TTY.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Van L]

>>> Yes, the current shade of red is too glaring.
>> 
>> #ee2d3d is less glaring.
> 
> I see that the closest color for this is named "brown2".
> It's not required to always use colors with names,
> but in this case "brown2" is very close.  Another close
> candidates are "red2" and "firebrick2”.

Red2 (#ee0000) might be invisible to red-color blindness.
It could be too glaring still depending on taste.

The name firebrick2 hints closer to a kind of red than brown2.

> Then for hi-green we could use "green3”.

The 'light green' is easier on the eye, it seems to my eye
not having exclusively one color component in the RGB is better.

> Regarding your idea of using rainbow colors, the problem
> is that on TTY there are only these colors:
> 
> red, green, yellow, blue, magenta, cyan
> 
> hi-blue face uses cyan color, not blue, and
> hi-pink face uses magenta color, not red.
> 
> Since hi-yellow uses yellow, and hi-green uses green already,
> unfortunately there are no other colors available on TTY.

That’s a rabbit hole beyond scope. I am afraid.

If only the `Hi Green B' and `Hi Red B' are adjusted, or only the `Hi Green B’ is 
that improves the existing defaultsetting.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

>> I see that the closest color for this is named "brown2".
>> It's not required to always use colors with names,
>> but in this case "brown2" is very close.  Another close
>> candidates are "red2" and "firebrick2".
>
> Red2 (#ee0000) might be invisible to red-color blindness.
> It could be too glaring still depending on taste.
>
> The name firebrick2 hints closer to a kind of red than brown2.

OK, firebrick2 is a good color for `Hi Red B'.

>> Then for hi-green we could use "green3".
>
> The 'light green' is easier on the eye, it seems to my eye
> not having exclusively one color component in the RGB is better.

'light green' is almost white, so it's difficult to read on
white background when 'light green' is used as foreground color
in `Hi Green B'. This is the reason why 'light green' is used as
background color in `Hi Green', i.e. 'light green' is better
for background, not foreground.

>> Regarding your idea of using rainbow colors, the problem
>> is that on TTY there are only these colors:
>> 
>> red, green, yellow, blue, magenta, cyan
>> 
>> hi-blue face uses cyan color, not blue, and
>> hi-pink face uses magenta color, not red.
>> 
>> Since hi-yellow uses yellow, and hi-green uses green already,
>> unfortunately there are no other colors available on TTY.
>
> That's a rabbit hole beyond scope. I am afraid.

The same way as hi-yellow is defined to use yellow, and hi-green
to use green, we can define hi-blue to use blue color, and
hi-pink to use red color.  This will free cyan and magenta
to use.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Van L]

>> The name firebrick2 hints closer to a kind of red than brown2.
> 
> OK, firebrick2 is a good color for `Hi Red B’.

ok x 2.

> 
>>> Then for hi-green we could use "green3".
>> 
>> The 'light green' is easier on the eye, it seems to my eye
>> not having exclusively one color component in the RGB is better.
> 
> 'light green' is almost white, so it's difficult to read on
> white background when 'light green' is used as foreground color

Yes. I agree. Let’s not have that.

> in `Hi Green B'. This is the reason why 'light green' is used as
> background color in `Hi Green', i.e. 'light green' is better
> for background, not foreground.

'light green'
  for hi-green is actually the background color highlight and black is foreground for the text

'darkgreen'
  was what we could agree on for `Hi Green B’ 

We are probably in agreement.

> 
>>> Regarding your idea of using rainbow colors, the problem
>>> is that on TTY there are only these colors:
>>> 
>>> red, green, yellow, blue, magenta, cyan
>>> 
>>> hi-blue face uses cyan color, not blue, and
>>> hi-pink face uses magenta color, not red.
>>> 
>>> Since hi-yellow uses yellow, and hi-green uses green already,
>>> unfortunately there are no other colors available on TTY.
>> 
>> That's a rabbit hole beyond scope. I am afraid.
> 
> The same way as hi-yellow is defined to use yellow, and hi-green
> to use green, we can define hi-blue to use blue color, and
> hi-pink to use red color.  This will free cyan and magenta
> to use.

I’ve never been able to workout the color choices for TTY and use 'emacs --color=no'

I have no opinion in relation to the TTY color choices.

The rainbow/artist’s coloring pencils theme for hi-faces is nicer to have for the wm-frame-windowing environment.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

> 'darkgreen'
>   was what we could agree on for `Hi Green B’ 

'darkgreen' is almost black, and indistinguishable from
the default black foreground color.  A better color
for `Hi Green B' is 'green3'.

>> The same way as hi-yellow is defined to use yellow, and hi-green
>> to use green, we can define hi-blue to use blue color, and
>> hi-pink to use red color.  This will free cyan and magenta
>> to use.

I guess there are no hi-magenta and hi-cyan faces because
Isearch uses the magenta color for the current match and the
cyan color for lazy-highlighted matches.

But OTOH, on TTY magenta and cyan are used from hi-pink and hi-blue,
and there is no problem, so we can define two new hi-lock faces.

> The rainbow/artist’s coloring pencils theme for hi-faces is nicer to
> have for the wm-frame-windowing environment.

emacs/lisp/textmodes/artist.el doesn't have many colors,
and colors from the rainbow-delimiters packages are too dull.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Van L]

>> 'darkgreen'
>>  was what we could agree on for `Hi Green B’ 
> 
> 'darkgreen' is almost black

That would be 'darkgreen' foreground on white background for `Hi Green B'.

>>> The same way as hi-yellow is defined to use yellow, and hi-green
>>> to use green, we can define hi-blue to use blue color, and
>>> hi-pink to use red color.  This will free cyan and magenta
>>> to use.
> 
> I guess there are no hi-magenta and hi-cyan faces because
> Isearch uses the magenta color for the current match and the
> cyan color for lazy-highlighted matches.
> 
> But OTOH, on TTY magenta and cyan are used from hi-pink and hi-blue,
> and there is no problem, so we can define two new hi-lock faces.

My experience of TTY in color is that there a combinations that are totally unreadable to my eye, such as, darkblue on black.

> 
>> The rainbow/artist’s coloring pencils theme for hi-faces is nicer to
>> have for the wm-frame-windowing environment.
> 
> emacs/lisp/textmodes/artist.el doesn't have many colors,
> and colors from the rainbow-delimiters packages are too dull.

The ROYGBIV palette for hi-lock-faces as theme.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

>>> The rainbow/artist’s coloring pencils theme for hi-faces is nicer to
>>> have for the wm-frame-windowing environment.
>
> The ROYGBIV palette for hi-lock-faces as theme.

There is one palette in vc-annotate-color-map, but it doesn't look good
when used for highlighting.

>>>> The same way as hi-yellow is defined to use yellow, and hi-green
>>>> to use green, we can define hi-blue to use blue color, and
>>>> hi-pink to use red color.  This will free cyan and magenta
>>>> to use.
>> 
>> I guess there are no hi-magenta and hi-cyan faces because
>> Isearch uses the magenta color for the current match and the
>> cyan color for lazy-highlighted matches.
>> 
>> But OTOH, on TTY magenta and cyan are used from hi-pink and hi-blue,
>> and there is no problem, so we can define two new hi-lock faces.

The existing hi-blue face's color "light blue" is closer to the existing
lazy-highlight face's color "paleturquoise" than to the new hi-cyan
face's color "DarkSlateGray1" proposed in the patch below, so this
color choice will be better then existing:

diff --git a/lisp/hi-lock.el b/lisp/hi-lock.el
index 08b58117dd..95d7f867df 100644
--- a/lisp/hi-lock.el
+++ b/lisp/hi-lock.el
@@ -157,8 +157,11 @@ hi-yellow
   :group 'hi-lock-faces)
 
 (defface hi-pink
-  '((((background dark)) (:background "pink" :foreground "black"))
-    (t (:background "pink")))
+  '((((min-colors 88) (background dark))
+     (:background "pink" :foreground "black"))
+    (((background dark)) (:background "red" :foreground "black"))
+    (((min-colors 88)) (:background "pink"))
+    (t (:background "red")))
   "Face for hi-lock mode."
   :group 'hi-lock-faces)
 
@@ -172,8 +175,29 @@ hi-green
   :group 'hi-lock-faces)
 
 (defface hi-blue
-  '((((background dark)) (:background "light blue" :foreground "black"))
-    (t (:background "light blue")))
+  '((((min-colors 88) (background dark))
+     (:background "light blue" :foreground "black"))
+    (((background dark)) (:background "blue" :foreground "black"))
+    (((min-colors 88)) (:background "light blue"))
+    (t (:background "blue")))
+  "Face for hi-lock mode."
+  :group 'hi-lock-faces)
+
+(defface hi-magenta
+  '((((min-colors 88) (background dark))
+     (:background "orchid1" :foreground "black"))
+    (((background dark)) (:background "magenta" :foreground "black"))
+    (((min-colors 88)) (:background "orchid1"))
+    (t (:background "magenta")))
+  "Face for hi-lock mode."
+  :group 'hi-lock-faces)
+
+(defface hi-cyan
+  '((((min-colors 88) (background dark))
+     (:background "DarkSlateGray1" :foreground "black"))
+    (((background dark)) (:background "cyan" :foreground "black"))
+    (((min-colors 88)) (:background "DarkSlateGray1"))
+    (t (:background "cyan")))
   "Face for hi-lock mode."
   :group 'hi-lock-faces)
 
@@ -189,13 +213,13 @@ hi-blue-b
   :group 'hi-lock-faces)
 
 (defface hi-green-b
-  '((((min-colors 88)) (:weight bold :foreground "green1"))
+  '((((min-colors 88)) (:weight bold :foreground "green3"))
     (t (:weight bold :foreground "green")))
   "Face for hi-lock mode."
   :group 'hi-lock-faces)
 
 (defface hi-red-b
-  '((((min-colors 88)) (:weight bold :foreground "red1"))
+  '((((min-colors 88)) (:weight bold :foreground "firebrick2"))
     (t (:weight bold :foreground "red")))
   "Face for hi-lock mode."
   :group 'hi-lock-faces)
@@ -216,8 +240,8 @@ hi-lock-interactive-patterns
 (define-obsolete-variable-alias 'hi-lock-face-history
                                 'hi-lock-face-defaults "23.1")
 (defvar hi-lock-face-defaults
-  '("hi-yellow" "hi-pink" "hi-green" "hi-blue" "hi-black-b"
-    "hi-blue-b" "hi-red-b" "hi-green-b" "hi-black-hb")
+  '("hi-yellow" "hi-pink" "hi-green" "hi-blue" "hi-magenta" "hi-cyan"
+    "hi-black-b" "hi-blue-b" "hi-red-b" "hi-green-b" "hi-black-hb")
   "Default faces for hi-lock interactive functions.")
 
 (define-obsolete-variable-alias 'hi-lock-regexp-history

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Van L]

> There is one palette in vc-annotate-color-map, but it doesn't look good
> when used for highlighting.

Also, for me, where default face is black/gray (fore/background) 
the mouse button one-to-three transient highlight doesn’t look good.
It is something dark which makes the black text hard to read.

> 
>>>>> The same way as hi-yellow is defined to use yellow, and hi-green
>>>>> to use green, we can define hi-blue to use blue color, and
>>>>> hi-pink to use red color.  This will free cyan and magenta
>>>>> to use.
>>> 
>>> I guess there are no hi-magenta and hi-cyan faces because
>>> Isearch uses the magenta color for the current match and the
>>> cyan color for lazy-highlighted matches.
>>> 
>>> But OTOH, on TTY magenta and cyan are used from hi-pink and hi-blue,
>>> and there is no problem, so we can define two new hi-lock faces.
> 
> The existing hi-blue face's color "light blue" is closer to the existing
> lazy-highlight face's color "paleturquoise" than to the new hi-cyan
> face's color "DarkSlateGray1" proposed in the patch below, 

Thanks. 'DarkSlateGray1' is a totally unexpected cyan.

Will the patch need to wait years before if backprops from 27 to 26.x release?

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Fri, 23 Nov 2018 11:56:04 +1100
> Cc: 33398@debbugs.gnu.org
> 
> Will the patch need to wait years before if backprops from 27 to 26.x release?

It will never be backported.  Once committed to master, it will appear
in Emacs 27.1.  Interested users could meanwhile customize the hi-lock
faces in their init files.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Van L]

> It will never be backported.

That’s too sad.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Fri, 23 Nov 2018 22:22:45 +1100
> Cc: juri@linkov.net,
>  33398@debbugs.gnu.org
> 
> > It will never be backported.
> 
> That’s too sad.

Why sad?  Faces are easily customized; people who don't like the
default looks of a face can customize it as they see fit.  There's no
need to wait for an Emacs release that changes the defaults.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Fri, 23 Nov 2018 00:16:46 +0200
> Cc: 33398@debbugs.gnu.org
> 
> The existing hi-blue face's color "light blue" is closer to the existing
> lazy-highlight face's color "paleturquoise" than to the new hi-cyan
> face's color "DarkSlateGray1" proposed in the patch below, so this
> color choice will be better then existing:
> 
> diff --git a/lisp/hi-lock.el b/lisp/hi-lock.el
> index 08b58117dd..95d7f867df 100644
> --- a/lisp/hi-lock.el
> +++ b/lisp/hi-lock.el
> @@ -157,8 +157,11 @@ hi-yellow
>    :group 'hi-lock-faces)
>  
>  (defface hi-pink
> -  '((((background dark)) (:background "pink" :foreground "black"))
> -    (t (:background "pink")))
> +  '((((min-colors 88) (background dark))
> +     (:background "pink" :foreground "black"))
> +    (((background dark)) (:background "red" :foreground "black"))
> +    (((min-colors 88)) (:background "pink"))
> +    (t (:background "red")))
>    "Face for hi-lock mode."
>    :group 'hi-lock-faces)

Thanks for working on this, but unfortunately changing the default
colors for Emacs faces is not that easy (which is why we do that only
very rarely).  You cannot test your colors in just two points: 8-color
TTY and 256-color display (you probably used a GUI frame?).  For
starters, there's the 16-color TTY, where according to my testing your
changes are for the worse.  And I would also suggest to test with a
88-color TTY.  You need to test for both dark and light backgrounds.

In general, if the automatic color translation in tty-colors.el does a
good job (you can test that by specifying the X color and watching the
result), it is best not to have a special definition for the
corresponding min-colors.  So, for example, for the new hi-magenta and
hi-cyan faces you introduce, please see whether you really need the
definitions for less than 88 colors -- they will only be needed if the
automatic translation produces unpleasant results.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

>>  (defface hi-pink
>> -  '((((background dark)) (:background "pink" :foreground "black"))
>> -    (t (:background "pink")))
>> +  '((((min-colors 88) (background dark))
>> +     (:background "pink" :foreground "black"))
>> +    (((background dark)) (:background "red" :foreground "black"))
>> +    (((min-colors 88)) (:background "pink"))
>> +    (t (:background "red")))
>>    "Face for hi-lock mode."
>>    :group 'hi-lock-faces)
>
> Thanks for working on this, but unfortunately changing the default
> colors for Emacs faces is not that easy (which is why we do that only
> very rarely).

I understand that face changing is very sensitive area, so I don't insist
on these changes if the result is worse.  What I was trying to do is to
add 2 more default colors: the current 4 is too small number of the default
background colors, so adding 2 colors will at least cover all available
6 non-black-white colors on a 8-color TTY.

> You cannot test your colors in just two points: 8-color TTY and
> 256-color display (you probably used a GUI frame?).  For starters,
> there's the 16-color TTY, where according to my testing your changes
> are for the worse.  And I would also suggest to test with a 88-color
> TTY.  You need to test for both dark and light backgrounds.

I tested these colors with TERM=xterm-256color where running

emacs -Q -nw --color=8 -f list-colors-display

displays a list of 8 colors, good.  But running

emacs -Q -nw --color=16 -f list-colors-display

displays a list of 256 colors, the same number of colors properly displayed by

emacs -Q -nw --color=256 -f list-colors-display

Is this a bug in Emacs?  Could you recommend a better way
to test a 16-color palette on a TTY?

> In general, if the automatic color translation in tty-colors.el does a
> good job (you can test that by specifying the X color and watching the
> result), it is best not to have a special definition for the
> corresponding min-colors.  So, for example, for the new hi-magenta and
> hi-cyan faces you introduce, please see whether you really need the
> definitions for less than 88 colors -- they will only be needed if the
> automatic translation produces unpleasant results.

For the new faces I copied the defface spec conditions from the existing
faces hi-yellow and hi-green that have separate conditions for less than
88 colors.  But we could drop unnecessary conditions here as well.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: van@scratch.space,  33398@debbugs.gnu.org
> Date: Sat, 24 Nov 2018 23:29:15 +0200
> 
> >>  (defface hi-pink
> >> -  '((((background dark)) (:background "pink" :foreground "black"))
> >> -    (t (:background "pink")))
> >> +  '((((min-colors 88) (background dark))
> >> +     (:background "pink" :foreground "black"))
> >> +    (((background dark)) (:background "red" :foreground "black"))
> >> +    (((min-colors 88)) (:background "pink"))
> >> +    (t (:background "red")))
> >>    "Face for hi-lock mode."
> >>    :group 'hi-lock-faces)
> >
> > Thanks for working on this, but unfortunately changing the default
> > colors for Emacs faces is not that easy (which is why we do that only
> > very rarely).
> 
> I understand that face changing is very sensitive area, so I don't insist
> on these changes if the result is worse.  What I was trying to do is to
> add 2 more default colors: the current 4 is too small number of the default
> background colors, so adding 2 colors will at least cover all available
> 6 non-black-white colors on a 8-color TTY.

Then I don't understand why you also changed the faces we had
already.  Leaving them alone will lower the risk that someone will
become annoyed by the changes.

> emacs -Q -nw --color=8 -f list-colors-display
> 
> displays a list of 8 colors, good.  But running
> 
> emacs -Q -nw --color=16 -f list-colors-display
> 
> displays a list of 256 colors, the same number of colors properly displayed by
> 
> emacs -Q -nw --color=256 -f list-colors-display
> 
> Is this a bug in Emacs?

Not a bug, a subtlety: the only numeric argument you can reliably
submit to --color= is 8, because it alone has a standard set of
termcap/terminfo commands to set and reset colors.  Maybe we should
amend the documentation so that people don't expect other numbers to
work.

> Could you recommend a better way to test a 16-color palette on a
> TTY?

Use a 16-color terminfo entry.

> For the new faces I copied the defface spec conditions from the existing
> faces hi-yellow and hi-green that have separate conditions for less than
> 88 colors.  But we could drop unnecessary conditions here as well.

That some face does have such conditional color definitions doesn't
mean another face also should.  It depends on the results we get on
color-challenged terminals via color translation.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

>> >>  (defface hi-pink
>> >> -  '((((background dark)) (:background "pink" :foreground "black"))
>> >> -    (t (:background "pink")))
>> >> +  '((((min-colors 88) (background dark))
>> >> +     (:background "pink" :foreground "black"))
>> >> +    (((background dark)) (:background "red" :foreground "black"))
>> >> +    (((min-colors 88)) (:background "pink"))
>> >> +    (t (:background "red")))
>> >>    "Face for hi-lock mode."
>> >>    :group 'hi-lock-faces)
>> >
>> > Thanks for working on this, but unfortunately changing the default
>> > colors for Emacs faces is not that easy (which is why we do that only
>> > very rarely).
>> 
>> I understand that face changing is very sensitive area, so I don't insist
>> on these changes if the result is worse.  What I was trying to do is to
>> add 2 more default colors: the current 4 is too small number of the default
>> background colors, so adding 2 colors will at least cover all available
>> 6 non-black-white colors on a 8-color TTY.
>
> Then I don't understand why you also changed the faces we had
> already.  Leaving them alone will lower the risk that someone will
> become annoyed by the changes.

The problem is that the condition '(t (:background "pink"))' is
automatically translated to "magenta" on a 8-color TTY.  And in the
'hi-blue' face '(t (:background "light blue"))' is translated to "cyan".

So to add a new face with a "blue" background on a 8-color TTY
with the condition '(t (:background "blue"))' we have no suitable name
for a new face, become the most suitable name 'hi-blue' is already
taken by the existing face that is displayed as "cyan".

The same problem is with 'hi-pink' that is currently translated to
"magenta", not to "red" on a 8-color TTY.

>> emacs -Q -nw --color=8 -f list-colors-display
>> 
>> displays a list of 8 colors, good.  But running
>> 
>> emacs -Q -nw --color=16 -f list-colors-display
>> 
>> displays a list of 256 colors, the same number of colors properly displayed by
>> 
>> emacs -Q -nw --color=256 -f list-colors-display
>> 
>> Is this a bug in Emacs?
>
> Not a bug, a subtlety: the only numeric argument you can reliably
> submit to --color= is 8, because it alone has a standard set of
> termcap/terminfo commands to set and reset colors.  Maybe we should
> amend the documentation so that people don't expect other numbers to
> work.

Currently it's documented in (info "(emacs) Colors X")

‘--color=MODE’
...
     ‘NUM’
          ...
          Depending on your terminal’s capabilities, Emacs might be able
          to turn on a color mode for 8, 16, 88, or 256 as the value of NUM.

I guess the key point is "Depending on your terminal’s capabilities".
This might explain why values other than 8 and 256 are not supported.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: van@scratch.space,  33398@debbugs.gnu.org
> Date: Sun, 25 Nov 2018 22:25:25 +0200
> 
> The problem is that the condition '(t (:background "pink"))' is
> automatically translated to "magenta" on a 8-color TTY.  And in the
> 'hi-blue' face '(t (:background "light blue"))' is translated to "cyan".
> 
> So to add a new face with a "blue" background on a 8-color TTY
> with the condition '(t (:background "blue"))' we have no suitable name
> for a new face, become the most suitable name 'hi-blue' is already
> taken by the existing face that is displayed as "cyan".
> 
> The same problem is with 'hi-pink' that is currently translated to
> "magenta", not to "red" on a 8-color TTY.

(Converting "pink" to "magenta" and "lightblue" to "cyan" sounds fine
to me.)

So your problem is with the names of the faces?  Then may I suggest to
name the new faces hi-red and hi-deepblue?

> ‘--color=MODE’
> ...
>      ‘NUM’
>           ...
>           Depending on your terminal’s capabilities, Emacs might be able
>           to turn on a color mode for 8, 16, 88, or 256 as the value of NUM.
> 
> I guess the key point is "Depending on your terminal’s capabilities".
> This might explain why values other than 8 and 256 are not supported.

Right.  But this subtlety is slightly misleading.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

> So your problem is with the names of the faces?  Then may I suggest to
> name the new faces hi-red and hi-deepblue?

Maybe something like this, but I'm not sure because the red background would
be too glaring on 88 colors, but more readable orchid1 is not quite red.
Also blue would be too dark for a light background, but more readable
DarkSlateGray1 is not quite blue as its name suggests.

diff --git a/lisp/hi-lock.el b/lisp/hi-lock.el
index f503c2764b..223b1007a8 100644
--- a/lisp/hi-lock.el
+++ b/lisp/hi-lock.el
@@ -177,6 +177,24 @@ hi-blue
   "Face for hi-lock mode."
   :group 'hi-lock-faces)
 
+(defface hi-red
+  '((((min-colors 88) (background dark))
+     (:background "orchid1" :foreground "black"))
+    (((background dark)) (:background "red" :foreground "black"))
+    (((min-colors 88)) (:background "orchid1"))
+    (t (:background "red")))
+  "Face for hi-lock mode."
+  :group 'hi-lock-faces)
+
+(defface hi-deepblue
+  '((((min-colors 88) (background dark))
+     (:background "DarkSlateGray1" :foreground "black"))
+    (((background dark)) (:background "blue" :foreground "black"))
+    (((min-colors 88)) (:background "DarkSlateGray1"))
+    (t (:background "blue")))
+  "Face for hi-lock mode."
+  :group 'hi-lock-faces)
+
 (defface hi-black-b
   '((t (:weight bold)))
   "Face for hi-lock mode."
@@ -189,13 +207,13 @@ hi-blue-b
   :group 'hi-lock-faces)
 
 (defface hi-green-b
-  '((((min-colors 88)) (:weight bold :foreground "green1"))
+  '((((min-colors 88)) (:weight bold :foreground "green3"))
     (t (:weight bold :foreground "green")))
   "Face for hi-lock mode."
   :group 'hi-lock-faces)
 
 (defface hi-red-b
-  '((((min-colors 88)) (:weight bold :foreground "red1"))
+  '((((min-colors 88)) (:weight bold :foreground "firebrick2"))
     (t (:weight bold :foreground "red")))
   "Face for hi-lock mode."
   :group 'hi-lock-faces)
@@ -216,8 +234,8 @@ hi-lock-interactive-patterns
 (define-obsolete-variable-alias 'hi-lock-face-history
                                 'hi-lock-face-defaults "23.1")
 (defvar hi-lock-face-defaults
-  '("hi-yellow" "hi-pink" "hi-green" "hi-blue" "hi-black-b"
-    "hi-blue-b" "hi-red-b" "hi-green-b" "hi-black-hb")
+  '("hi-yellow" "hi-pink" "hi-green" "hi-blue" "hi-red" "hi-deepblue"
+    "hi-black-b" "hi-blue-b" "hi-red-b" "hi-green-b" "hi-black-hb")
   "Default faces for hi-lock interactive functions.")
 
 (define-obsolete-variable-alias 'hi-lock-regexp-history

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Van L <van@scratch.space>,  33398@debbugs.gnu.org
> Date: Tue, 27 Nov 2018 01:27:40 +0200
> 
> > So your problem is with the names of the faces?  Then may I suggest to
> > name the new faces hi-red and hi-deepblue?
> 
> Maybe something like this, but I'm not sure because the red background would
> be too glaring on 88 colors, but more readable orchid1 is not quite red.

Is OrangeRed better?

> Also blue would be too dark for a light background, but more readable
> DarkSlateGray1 is not quite blue as its name suggests.

That's okay, I think.

>  (defface hi-green-b
> -  '((((min-colors 88)) (:weight bold :foreground "green1"))
> +  '((((min-colors 88)) (:weight bold :foreground "green3"))
>      (t (:weight bold :foreground "green")))
>    "Face for hi-lock mode."
>    :group 'hi-lock-faces)
>  
>  (defface hi-red-b
> -  '((((min-colors 88)) (:weight bold :foreground "red1"))
> +  '((((min-colors 88)) (:weight bold :foreground "firebrick2"))
>      (t (:weight bold :foreground "red")))
>    "Face for hi-lock mode."
>    :group 'hi-lock-faces)

So why are you still changing the existing faces?  Not that I see any
problem with these changes on low-color TTYs, but still: why change?

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

>> Maybe something like this, but I'm not sure because the red background would
>> be too glaring on 88 colors, but more readable orchid1 is not quite red.
>
> Is OrangeRed better?

OrangeRed is not better than red, but simply Orange looks much better,
so a new face could be named hi-orange.

>> Also blue would be too dark for a light background, but more readable
>> DarkSlateGray1 is not quite blue as its name suggests.
>
> That's okay, I think.

I found a better color: Aquamarine, it's very close to DarkSlateGray1,
but it's name has a stronger association with blue.

>>  (defface hi-green-b
>> -  '((((min-colors 88)) (:weight bold :foreground "green1"))
>> +  '((((min-colors 88)) (:weight bold :foreground "green3"))
>>      (t (:weight bold :foreground "green")))
>>    "Face for hi-lock mode."
>>    :group 'hi-lock-faces)
>>
>>  (defface hi-red-b
>> -  '((((min-colors 88)) (:weight bold :foreground "red1"))
>> +  '((((min-colors 88)) (:weight bold :foreground "firebrick2"))
>>      (t (:weight bold :foreground "red")))
>>    "Face for hi-lock mode."
>>    :group 'hi-lock-faces)
>
> So why are you still changing the existing faces?  Not that I see any
> problem with these changes on low-color TTYs, but still: why change?

The original complain from Van L was that "green1" and "red1" are
too glaring, and I agree.  The new colors are dimmed down versions
that are more easy to read.

diff --git a/lisp/hi-lock.el b/lisp/hi-lock.el
index f503c2764b..f66a512755 100644
--- a/lisp/hi-lock.el
+++ b/lisp/hi-lock.el
@@ -177,6 +177,24 @@ hi-blue
   "Face for hi-lock mode."
   :group 'hi-lock-faces)
 
+(defface hi-orange
+  '((((min-colors 88) (background dark))
+     (:background "orange" :foreground "black"))
+    (((background dark)) (:background "red" :foreground "black"))
+    (((min-colors 88)) (:background "orange"))
+    (t (:background "red")))
+  "Face for hi-lock mode."
+  :group 'hi-lock-faces)
+
+(defface hi-aquamarine
+  '((((min-colors 88) (background dark))
+     (:background "aquamarine" :foreground "black"))
+    (((background dark)) (:background "blue" :foreground "black"))
+    (((min-colors 88)) (:background "aquamarine"))
+    (t (:background "blue")))
+  "Face for hi-lock mode."
+  :group 'hi-lock-faces)
+
 (defface hi-black-b
   '((t (:weight bold)))
   "Face for hi-lock mode."
@@ -189,13 +207,13 @@ hi-blue-b
   :group 'hi-lock-faces)
 
 (defface hi-green-b
-  '((((min-colors 88)) (:weight bold :foreground "green1"))
+  '((((min-colors 88)) (:weight bold :foreground "green3"))
     (t (:weight bold :foreground "green")))
   "Face for hi-lock mode."
   :group 'hi-lock-faces)
 
 (defface hi-red-b
-  '((((min-colors 88)) (:weight bold :foreground "red1"))
+  '((((min-colors 88)) (:weight bold :foreground "firebrick2"))
     (t (:weight bold :foreground "red")))
   "Face for hi-lock mode."
   :group 'hi-lock-faces)
@@ -216,8 +234,8 @@ hi-lock-interactive-patterns
 (define-obsolete-variable-alias 'hi-lock-face-history
                                 'hi-lock-face-defaults "23.1")
 (defvar hi-lock-face-defaults
-  '("hi-yellow" "hi-pink" "hi-green" "hi-blue" "hi-black-b"
-    "hi-blue-b" "hi-red-b" "hi-green-b" "hi-black-hb")
+  '("hi-yellow" "hi-pink" "hi-green" "hi-blue" "hi-orange" "hi-aquamarine"
+    "hi-black-b" "hi-blue-b" "hi-red-b" "hi-green-b" "hi-black-hb")
   "Default faces for hi-lock interactive functions.")
 
 (define-obsolete-variable-alias 'hi-lock-regexp-history

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

>>> Maybe something like this, but I'm not sure because the red background would
>>> be too glaring on 88 colors, but more readable orchid1 is not quite red.
>>
>> Is OrangeRed better?
>
> OrangeRed is not better than red, but simply Orange looks much better,
> so a new face could be named hi-orange.

After trying to use Orange, I see it's too saturated, that is bad for
light backgrounds.  But I found a much better color: Gold.  It is still
related to red because gold can be reddish in an alloy with copper.

diff --git a/lisp/hi-lock.el b/lisp/hi-lock.el
index f503c2764b..9cfcdf9916 100644
--- a/lisp/hi-lock.el
+++ b/lisp/hi-lock.el
@@ -177,6 +177,24 @@ hi-blue
   "Face for hi-lock mode."
   :group 'hi-lock-faces)
 
+(defface hi-gold
+  '((((min-colors 88) (background dark))
+     (:background "gold" :foreground "black"))
+    (((background dark)) (:background "red" :foreground "black"))
+    (((min-colors 88)) (:background "gold"))
+    (t (:background "red")))
+  "Face for hi-lock mode."
+  :group 'hi-lock-faces)
+
+(defface hi-aquamarine
+  '((((min-colors 88) (background dark))
+     (:background "aquamarine" :foreground "black"))
+    (((background dark)) (:background "blue" :foreground "black"))
+    (((min-colors 88)) (:background "aquamarine"))
+    (t (:background "blue")))
+  "Face for hi-lock mode."
+  :group 'hi-lock-faces)
+
 (defface hi-black-b
   '((t (:weight bold)))
   "Face for hi-lock mode."
@@ -189,13 +207,13 @@ hi-blue-b
   :group 'hi-lock-faces)
 
 (defface hi-green-b
-  '((((min-colors 88)) (:weight bold :foreground "green1"))
+  '((((min-colors 88)) (:weight bold :foreground "green3"))
     (t (:weight bold :foreground "green")))
   "Face for hi-lock mode."
   :group 'hi-lock-faces)
 
 (defface hi-red-b
-  '((((min-colors 88)) (:weight bold :foreground "red1"))
+  '((((min-colors 88)) (:weight bold :foreground "firebrick2"))
     (t (:weight bold :foreground "red")))
   "Face for hi-lock mode."
   :group 'hi-lock-faces)
@@ -216,8 +234,8 @@ hi-lock-interactive-patterns
 (define-obsolete-variable-alias 'hi-lock-face-history
                                 'hi-lock-face-defaults "23.1")
 (defvar hi-lock-face-defaults
-  '("hi-yellow" "hi-pink" "hi-green" "hi-blue" "hi-black-b"
-    "hi-blue-b" "hi-red-b" "hi-green-b" "hi-black-hb")
+  '("hi-yellow" "hi-pink" "hi-green" "hi-blue" "hi-gold" "hi-aquamarine"
+    "hi-black-b" "hi-blue-b" "hi-red-b" "hi-green-b" "hi-black-hb")
   "Default faces for hi-lock interactive functions.")
 
 (define-obsolete-variable-alias 'hi-lock-regexp-history

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Van L <van@scratch.space>,  33398@debbugs.gnu.org
> Date: Thu, 29 Nov 2018 01:06:50 +0200
> 
> >>> Maybe something like this, but I'm not sure because the red background would
> >>> be too glaring on 88 colors, but more readable orchid1 is not quite red.
> >>
> >> Is OrangeRed better?
> >
> > OrangeRed is not better than red, but simply Orange looks much better,
> > so a new face could be named hi-orange.
> 
> After trying to use Orange, I see it's too saturated, that is bad for
> light backgrounds.  But I found a much better color: Gold.  It is still
> related to red because gold can be reddish in an alloy with copper.

I don't see how "gold" can be translated to "red", sorry.  It
translates to yellow shades on both 8- and 16-color TTYs, as expected.
Did you try "IndianRed" instead?

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

>> >>> Maybe something like this, but I'm not sure because the red background would
>> >>> be too glaring on 88 colors, but more readable orchid1 is not quite red.
>> >>
>> >> Is OrangeRed better?
>> >
>> > OrangeRed is not better than red, but simply Orange looks much better,
>> > so a new face could be named hi-orange.
>>
>> After trying to use Orange, I see it's too saturated, that is bad for
>> light backgrounds.  But I found a much better color: Gold.  It is still
>> related to red because gold can be reddish in an alloy with copper.
>
> I don't see how "gold" can be translated to "red", sorry.  It
> translates to yellow shades on both 8- and 16-color TTYs, as expected.
> Did you try "IndianRed" instead?

Unfortunately, "IndianRed" is so dark that it's unreadable.
Whereas "Gold" is so prefect, that I can't find a replacement.
But are translations really required?  I created a definition
that works well on all environments (I see that "gold" looks good
on a graphical terminal, but on a 256-color TTY "orange" is better).
Do you see a problem with these best-looking faces?

(defface hi-gold
  '((((min-colors 88) (type x w32 ns)) (:background "gold"))
    (((min-colors 88)) (:background "orange"))
    (((min-colors 16)) (:background "red"))
    (t (:background "red")))
  "Face for hi-lock mode."
  :group 'hi-lock-faces)

(defface hi-aquamarine
  '((((min-colors 88)) (:background "aquamarine"))
    (((min-colors 16)) (:background "blue"))
    (t (:background "blue")))
  "Face for hi-lock mode."
  :group 'hi-lock-faces)

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: van@scratch.space,  33398@debbugs.gnu.org
> Date: Fri, 30 Nov 2018 00:29:21 +0200
> 
> > I don't see how "gold" can be translated to "red", sorry.  It
> > translates to yellow shades on both 8- and 16-color TTYs, as expected.
> > Did you try "IndianRed" instead?
> 
> Unfortunately, "IndianRed" is so dark that it's unreadable.
> Whereas "Gold" is so prefect, that I can't find a replacement.
> But are translations really required?  I created a definition
> that works well on all environments (I see that "gold" looks good
> on a graphical terminal, but on a 256-color TTY "orange" is better).
> Do you see a problem with these best-looking faces?

Yes, I definitely see a problem when a face called "hi-gold" is
displayed as red on some devices.

Are you saying that none of the shades of red in rgb.txt is good
enough to use on GUI frames where "red" is used on TTYs?  I find that
hard to believe.  What about DarkOrange, what about Coral, what about
OrangeRed, what about LightSalmon[1-3], what about sienna[1-3], what
about IndianRed1, what about tomato[1-3], chocolate[1-3], etc.?  Call
it "hi-reddish" if you must, just don't have something called "gold"
look red on TTYs, please.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

>> > I don't see how "gold" can be translated to "red", sorry.  It
>> > translates to yellow shades on both 8- and 16-color TTYs, as expected.
>> > Did you try "IndianRed" instead?
>> 
>> Unfortunately, "IndianRed" is so dark that it's unreadable.
>> Whereas "Gold" is so prefect, that I can't find a replacement.
>> But are translations really required?  I created a definition
>> that works well on all environments (I see that "gold" looks good
>> on a graphical terminal, but on a 256-color TTY "orange" is better).
>> Do you see a problem with these best-looking faces?
>
> Yes, I definitely see a problem when a face called "hi-gold" is
> displayed as red on some devices.

Sorry for asking about such minor issue, but I have another idea below.

> Are you saying that none of the shades of red in rgb.txt is good
> enough to use on GUI frames where "red" is used on TTYs?  I find that
> hard to believe.  What about DarkOrange, what about Coral, what about
> OrangeRed, what about LightSalmon[1-3], what about sienna[1-3], what
> about IndianRed1, what about tomato[1-3], chocolate[1-3], etc.?

Among all these colors the least bad is LightSalmon,
but it has the same saturation as Orange, not as much lighter Gold
that would be the best choice.

> Call it "hi-reddish" if you must, just don't have something called
> "gold" look red on TTYs, please.

We can call it "hi-redgold" because such thing really exists:
https://en.wikipedia.org/wiki/Red_gold

(defface hi-redgold
  '((((min-colors 88) (type x w32 ns)) (:background "gold"))
    (((min-colors 88)) (:background "orange"))
    (((min-colors 16)) (:background "red"))
    (t (:background "red")))
  "Face for hi-lock mode."
  :group 'hi-lock-faces)

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Van L]

> Among all these colors the least bad is LightSalmon,
> but it has the same saturation as Orange, not as much lighter Gold
> that would be the best choice.

After experimenting with salmon, 
I discovered coral when looking for 
living coral which happens to be 
a color for makeup.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

>> Among all these colors the least bad is LightSalmon,
>> but it has the same saturation as Orange, not as much lighter Gold
>> that would be the best choice.
>
> After experimenting with salmon,
> I discovered coral when looking for
> living coral which happens to be
> a color for makeup.

The problem is that Coral is too saturated.

Please note that both Coral and LightSalmon
translate to yellow on tty, not to red as needed.

So we need to abandon an idea to find such a color
that translates to red on tty, and use separate colors
for tty and 88-color displays.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: van@scratch.space,  33398@debbugs.gnu.org
> Date: Wed, 19 Dec 2018 02:36:33 +0200
> 
> > Call it "hi-reddish" if you must, just don't have something called
> > "gold" look red on TTYs, please.
> 
> We can call it "hi-redgold" because such thing really exists:
> https://en.wikipedia.org/wiki/Red_gold

If that's the best we can do...

> (defface hi-redgold
>   '((((min-colors 88) (type x w32 ns)) (:background "gold"))
>     (((min-colors 88)) (:background "orange"))
>     (((min-colors 16)) (:background "red"))
>     (t (:background "red")))

How about this instead:

(defface hi-redgold
  '((((min-colors 8)) (:background "red"))
    (t (:background "gold")))
  "Face for hi-lock mode."
  :group 'hi-lock-faces)

I see no reason to use "red" on 16-color terminals, nor "orange" on
color TTYs with at least 88 colors.  The translation of "gold" should
be good enough in those cases.  Isn't it?

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

>> > Call it "hi-reddish" if you must, just don't have something called
>> > "gold" look red on TTYs, please.
>>
>> We can call it "hi-redgold" because such thing really exists:
>> https://en.wikipedia.org/wiki/Red_gold
>
> If that's the best we can do...

Another variant that you suggested to try LightSalmon looks good too,
and maybe even better than Gold because Gold is too close to the
existing hi-yellow, whereas LightSalmon is quite far away from the
existing hi-pink.

> How about this instead:
>
> (defface hi-redgold
>   '((((min-colors 8)) (:background "red"))
>     (t (:background "gold")))
>   "Face for hi-lock mode."
>   :group 'hi-lock-faces)
>
> I see no reason to use "red" on 16-color terminals, nor "orange" on
> color TTYs with at least 88 colors.  The translation of "gold" should
> be good enough in those cases.  Isn't it?

I tried, and it used "red" even on 88-colors.

But given that LightSalmon is a good choice, I copied the same
definitions from other faces, substituted with new colors and they
look good on all environments:

(defface hi-salmon
  '((((min-colors 88) (background dark))
     (:background "light salmon" :foreground "black"))
    (((background dark)) (:background "red" :foreground "black"))
    (((min-colors 88)) (:background "light salmon"))
    (t (:background "red")))
  "Face for hi-lock mode."
  :group 'hi-lock-faces)

(defface hi-aquamarine
  '((((min-colors 88) (background dark))
     (:background "aquamarine" :foreground "black"))
    (((background dark)) (:background "blue" :foreground "black"))
    (((min-colors 88)) (:background "aquamarine"))
    (t (:background "blue")))
  "Face for hi-lock mode."
  :group 'hi-lock-faces)

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Van L]

>> The translation of "gold" should
>> be good enough in those cases.  Isn't it?

The American English entry in the Dictionary has

// gold, in the figurative language of the people,
// was “the tears wept by the sun.” 

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: van@scratch.space,  33398@debbugs.gnu.org
> Date: Wed, 19 Dec 2018 23:40:08 +0200
> 
> > (defface hi-redgold
> >   '((((min-colors 8)) (:background "red"))
> >     (t (:background "gold")))
> >   "Face for hi-lock mode."
> >   :group 'hi-lock-faces)
> >
> > I see no reason to use "red" on 16-color terminals, nor "orange" on
> > color TTYs with at least 88 colors.  The translation of "gold" should
> > be good enough in those cases.  Isn't it?
> 
> I tried, and it used "red" even on 88-colors.

I don't have access to such a terminal, but on a 16-color TTY "gold"
displays as bright yellow, which is definitely not red.  So I'm
surprised you see red on a 88-color TTY.

> But given that LightSalmon is a good choice, I copied the same
> definitions from other faces, substituted with new colors and they
> look good on all environments:
> 
> (defface hi-salmon
>   '((((min-colors 88) (background dark))
>      (:background "light salmon" :foreground "black"))
>     (((background dark)) (:background "red" :foreground "black"))
>     (((min-colors 88)) (:background "light salmon"))
>     (t (:background "red")))
>   "Face for hi-lock mode."
>   :group 'hi-lock-faces)
> 
> (defface hi-aquamarine
>   '((((min-colors 88) (background dark))
>      (:background "aquamarine" :foreground "black"))
>     (((background dark)) (:background "blue" :foreground "black"))
>     (((min-colors 88)) (:background "aquamarine"))
>     (t (:background "blue")))
>   "Face for hi-lock mode."
>   :group 'hi-lock-faces)

Thanks.

bug#33398: 26.1, netbsd-8; Hi Lock Faces, Hi Green B, default setting suggestion

[Juri Linkov]

>> > (defface hi-redgold
>> >   '((((min-colors 8)) (:background "red"))
>> >     (t (:background "gold")))
>> >   "Face for hi-lock mode."
>> >   :group 'hi-lock-faces)
>> >
>> > I see no reason to use "red" on 16-color terminals, nor "orange" on
>> > color TTYs with at least 88 colors.  The translation of "gold" should
>> > be good enough in those cases.  Isn't it?
>>
>> I tried, and it used "red" even on 88-colors.
>
> I don't have access to such a terminal, but on a 16-color TTY "gold"
> displays as bright yellow, which is definitely not red.  So I'm
> surprised you see red on a 88-color TTY.

Actually, I meant that I see red on a 88-color graphical display.

>> But given that LightSalmon is a good choice, I copied the same
>> definitions from other faces, substituted with new colors and they
>> look good on all environments:
>>
>> (defface hi-salmon
>>   '((((min-colors 88) (background dark))
>>      (:background "light salmon" :foreground "black"))
>>     (((background dark)) (:background "red" :foreground "black"))
>>     (((min-colors 88)) (:background "light salmon"))
>>     (t (:background "red")))
>>   "Face for hi-lock mode."
>>   :group 'hi-lock-faces)
>>
>> (defface hi-aquamarine
>>   '((((min-colors 88) (background dark))
>>      (:background "aquamarine" :foreground "black"))
>>     (((background dark)) (:background "blue" :foreground "black"))
>>     (((min-colors 88)) (:background "aquamarine"))
>>     (t (:background "blue")))
>>   "Face for hi-lock mode."
>>   :group 'hi-lock-faces)
>
> Thanks.

Installed to master and closed.  It seems there is no need to update NEWS
because the users will see themselves two new colors added.