prompt colors bug? also possible feature add

prompt colors bug? also possible feature add

[Jim]

[-- Attachment #1.1: Type: text/plain, Size: 911 bytes --]

Hi all,

While working on colors and prompts I noticed that gray and grey
do not work in a prompt. But in the colors function it states:

# This is inaccurate, but the prompt theme system needs it.

for k in grey gray; do
  color[$k]=${color[black]}
  color[fg-$k]=${color[$k]}
  color[bg-$k]=${color[bg-black]}
done

Also wondering, since bright colors were added to colors, were they also
going to be included in prompts? That said, my $0.02 - I'm happy that all
16 colors are there in numbers 0 thru 15 and works as expected.

Is there any reason gray and grey couldn't be set correctly by using
\e[38;5;8m
and \e[48;5;8m?  Just a thought. Even the linux console supports all 16
colors.
it just doesn't support bold.

ZSH_PATCHLEVEL zsh-5.9-208-gf80ad32

Attached is a function I wrote "test_prompt_output.txt", and two png files
prompt_test_on_black_bg.png
prompt_test_on_white_bg.png

Regards,

Jim Murphy

[-- Attachment #1.2: Type: text/html, Size: 1262 bytes --]

[-- Attachment #2: test_prompt_colors.txt --]
[-- Type: text/plain, Size: 502 bytes --]

emulate -L zsh -o extendedglob
local     E N
local     CNs
CNs=(black red green yellow blue magenta cyan white grey gray
    bright-gray bright-red bright-green bright-yellow bright-blue
    bright-magenta bright-cyan bright-white)
for N ({0..15}) {
  TP="%K{$N}%n@%m%k %B%F{1}%(4~|...|)%1~%F{15} %# %b%f%k"
  print -- "${(l.2.. .)N}  ${(%)TP}"
}
for E ($CNs) {
  TP="%K{$E}%n@%m%k %B%F{1}%(4~|...|)%1~%F{15} %# %b%f%k"
  print -- "${(l.14.. .)E}  ${(%)TP}"
}
# vim: ts=2 sw=2 sts=2 sta ai et ft=zsh :

[-- Attachment #3: prompt_test_on_white_bg.png --]
[-- Type: image/png, Size: 17591 bytes --]

[-- Attachment #4: prompt_test_on_black_bg.png --]
[-- Type: image/png, Size: 73991 bytes --]

Re: prompt colors bug? also possible feature add

[Bart Schaefer]

On Thu, Aug 17, 2023 at 3:19 PM Jim <linux.tech.guy@gmail.com> wrote:
>
> While working on colors and prompts I noticed that gray and grey
> do not work in a prompt. But in the colors function it states:
>
> # This is inaccurate, but the prompt theme system needs it.

Not the built-in prompt escapes, the prompt themes installable via
  autoload prompinit
  promptinit
  prompt fade
(for example)

Re: prompt colors bug? also possible feature add

[Jim]

[-- Attachment #1.1: Type: text/plain, Size: 1505 bytes --]

Hi again,

On Thu, Aug 17, 2023 at 6:23 PM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Thu, Aug 17, 2023 at 3:19 PM Jim <linux.tech.guy@gmail.com> wrote:
> >
> > While working on colors and prompts I noticed that gray and grey
> > do not work in a prompt. But in the colors function it states:
> >
> > # This is inaccurate, but the prompt theme system needs it.
>
> Not the built-in prompt escapes, the prompt themes installable via
>   autoload prompinit
>   promptinit
>   prompt fade
> (for example)
>

Not sure if I'm barking up the wrong tree ...  Did some further testing
with an actual
prompt adam2 (alt_02 is some prep work for adding vcs_info -- tested on
just adam2
with the same results). When I tried to get "grey" or "gray" the color
defaulted back to
the terminal default(in my case green). Yet using numbers 7 & 8 output as
would be
expected(check user@host).  I guess the next questions is, does it only
work with
fade?

You used the example of prompt fade, but I tried bigfade with args as
described in
the function.  Having a hard time seeing grey, but maybe that has something
to do with
my virtual terminal or brightness setting. I included the results of my
testing in two
.png files.

Is there any consideration of adding bright-<color> to prompts? Just
curious.
As you can see, bright-color also defaults to terminal default(green).
Using numbers works for me.

If I misunderstood, sorry for the noise.

Regards,

Jim

[-- Attachment #1.2: Type: text/html, Size: 2168 bytes --]

[-- Attachment #2: prompt_color_test_bigfade.png --]
[-- Type: image/png, Size: 37525 bytes --]

[-- Attachment #3: prompt_color_test_for_gray.png --]
[-- Type: image/png, Size: 125079 bytes --]

Re: prompt colors bug? also possible feature add

[Bart Schaefer]

On Tue, Aug 22, 2023 at 5:37 PM Jim <linux.tech.guy@gmail.com> wrote:
>
> Not sure if I'm barking up the wrong tree ...

Not exactly ... previously I was pointing out that promises made by
the colors function have nothing to do with promises made by the
builtin prompt code.

> I guess the next questions is, does it only work with
> fade?

That's the only one that references it directly rather than by user
configuration, but it's the reason it appears in the colors arrays.

> Is there any consideration of adding bright-<color> to prompts? Just curious.

It has not been directly discussed.  That doesn't mean it couldn't
happen if someone wanted to put in the effort.  To the extent that
related things considered, it was decided that providing color numbers
was sufficient; color names are a throwback to when there were only
about 16 of them.  Sadly most of the prompt themes are from a similar
time, there haven't been any new ones contributed for some years.

Re: prompt colors bug? also possible feature add

[Jim]

[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]

On Tue, Aug 22, 2023 at 11:21 PM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Tue, Aug 22, 2023 at 5:37 PM Jim <linux.tech.guy@gmail.com> wrote:
> >
> > Not sure if I'm barking up the wrong tree ...
>
> Not exactly ... previously I was pointing out that promises made by
> the colors function have nothing to do with promises made by the
> builtin prompt code.
>
> > I guess the next questions is, does it only work with
> > fade?
>
> That's the only one that references it directly rather than by user
> configuration, but it's the reason it appears in the colors arrays.
>
>
The more I look into "functions/Prompts" and especially *fade and fire
there is no
change in color intensity or the use of "gray". It all has to do with the
background
color and the use of 4 block characters.  "Full Block" is a "solid" color
block.  The
other three blocks have dots as "fillers" with the background showing
through the
open spaces, they are "light shade", "medium shade" and "dark shade".
Because of
the background, this gives the illusion of four shades of a color.  Gray
isn't even
used AFAIKT. This is easier to see with some colors over others. When grey
is
specified, the color defaults to the default color of the virtual terminal
you are using.

I also thought  that prompts just supported the first 16 colors, <0-7>
normal
intensity, and <8-15> high intensity/bright.  But testing showed that
colors are
whatever the virtual terminal/TERM can support. <16-231> are all the 6x6x6
colors and <232-255> are the 24 shades of gray/grey. 'adam2' and 'oliver'
support bold by using the word bold in the output string. At least 'adam2'
and
'bigfade' allow a limited number of color changes from the command line.
One other thing, at least 'adam2' is set up to support '8bit' graphic
characters
by specifying '8bit' on the command line.

If anyone is interested, bigfade is a good one to test with. Help(-h) shows
the
following:

     prompt bigfade [<fade-bar> [<userhost> [<date> [<cwd>]]]]

To test instead of "prompt" use "prompt_preview_theme" .

example:
prompt_preview_theme bigfade grey red 75 148

Substitute the four args with whatever combinations of colors you want.

<black red green yellow blue magenta cyan white gray grey> or <0 .. 255 >

Hope this can be helpful to someone. I've learned a lot doing this.

Regards,

Jim

P.S. Bart, thanks for your input.

[-- Attachment #2: Type: text/html, Size: 3557 bytes --]

Re: prompt colors bug? also possible feature add

[Bart Schaefer]

On Wed, Aug 23, 2023 at 5:42 AM Jim <linux.tech.guy@gmail.com> wrote:
>
> The more I look into "functions/Prompts" and especially *fade and fire there is no
> change in color intensity or the use of "gray".

prompt_fade_setup:    prompt_preview_theme fade white grey blue
prompt_bigfade_setup:    prompt_preview_theme bigfade red white grey white

"colors" defines "grey" so as not to break those preview defaults, and
defines "gray" because some people spell differently.

> When grey is
> specified, the color defaults to the default color of the virtual terminal you are using.

I think that's because the virtual terminal is overriding "black".
Both gray and grey are defined as being identical to black.  Only the
xterm extended "bright" variants are actually gray.

Re: prompt colors bug? also possible feature add

[Jim]

[-- Attachment #1: Type: text/plain, Size: 2444 bytes --]

On Wed, Aug 23, 2023 at 10:45 PM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Wed, Aug 23, 2023 at 5:42 AM Jim <linux.tech.guy@gmail.com> wrote:
> >
> > The more I look into "functions/Prompts" and especially *fade and fire
> there is no
> > change in color intensity or the use of "gray".
>
> prompt_fade_setup:    prompt_preview_theme fade white grey blue
> prompt_bigfade_setup:    prompt_preview_theme bigfade red white grey white
>
> "colors" defines "grey" so as not to break those preview defaults, and
> defines "gray" because some people spell differently.
>
> > When grey is
> > specified, the color defaults to the default color of the virtual
> terminal you are using.
>
> I think that's because the virtual terminal is overriding "black".
> Both gray and grey are defined as being identical to black.  Only the
> xterm extended "bright" variants are actually gray.
>

First, I'm no C programmer so I could have missed something. I knew enough
C to allow
me to be a Unix/Linux system administrator and install patches and to
occasionally gen
my own patch, when needed. Looking through prompt.c I find the following:

/* Defines standard ANSI colour names in index order */
static const char *ansi_colours[] = {
    "black", "red", "green", "yellow", "blue", "magenta", "cyan", "white",
    "default", NULL
};

Grey/gray aren't defined as far as "I" can tell, anywhere. Should it?
That is for someone who knows more about this than I do.

But what is more interesting, it appears that prompt doesn't depend on
the "colors" function.

I commented out my prompt code in my .zshrc file.
Opened a new terminal.

% unset fg bg fg_bold  # cleared all colors associative arrays
% print -- ${fg[yellow]}This is a test  # outputs the terminal's default
color not yellow

Initiated prompts:
% autoload -Uz promptinit && promptinit
% prompt adam2

Ran several tests using:

% prompt_preview_theme fade <color1> <color2> <color3>

Substituted different color names for <colorN>

Prompt outputs all colors as defined in prompt.c.
Did not include gray/grey.

What is also interesting, prompt can output all colors defined by "number"
instead of a color name. e.g. 1 for red 9 for bright-red ...
The linux console will output colors 0..15
All virtual terminals(that I tested) outputs all 256 colors:  0..255

Anyway, just passing on what I found.

Regards,

Jim

[-- Attachment #2: Type: text/html, Size: 4361 bytes --]

Re: prompt colors bug? also possible feature add

[Bart Schaefer]

On Tue, Sep 19, 2023 at 6:15 PM Jim <linux.tech.guy@gmail.com> wrote:
>
> On Wed, Aug 23, 2023 at 10:45 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>>
>> On Wed, Aug 23, 2023 at 5:42 AM Jim <linux.tech.guy@gmail.com> wrote:
>> >
>> > The more I look into "functions/Prompts" and especially *fade and fire there is no
>> > change in color intensity or the use of "gray".
>>
>> prompt_fade_setup:    prompt_preview_theme fade white grey blue
>> prompt_bigfade_setup:    prompt_preview_theme bigfade red white grey white
>>
>> "colors" defines "grey" so as not to break those preview defaults, and
>> defines "gray" because some people spell differently.
>>
>> > When grey is
>> > specified, the color defaults to the default color of the virtual terminal you are using.
>>
>> I think that's because the virtual terminal is overriding "black".
>> Both gray and grey are defined as being identical to black.  Only the
>> xterm extended "bright" variants are actually gray.
>
> First, I'm no C programmer so I could have missed something. I knew enough C to allow
> me to be a Unix/Linux system administrator and install patches and to occasionally gen
> my own patch, when needed. Looking through prompt.c I find the following:
>
> /* Defines standard ANSI colour names in index order */
> static const char *ansi_colours[] = {
>     "black", "red", "green", "yellow", "blue", "magenta", "cyan", "white",
>     "default", NULL
> };
>
> Grey/gray aren't defined as far as "I" can tell, anywhere. Should it?

You keep changing the context of the discussion.  Everything you
excerpted from my previous message is about prompt themes and the
colors function.  I keep repeating that this has nothing to do with
the C code / the built-in prompt coloring.  The colors function
defines fg[grey] fg[gray] bg[grey] bg[grey] etc.

> But what is more interesting, it appears that prompt doesn't depend on
> the "colors" function.

We're confusing things again.  No, the built-in prompts do not depend
on the colors function.  Also no, the prompt themes typically do not
require the colors function.  In fact the only one that pretends to is
mine (prompt bart) and only because it presumes the fg array might
already exist.  However, many of the themes accept parameters, and you
can use the arrays created by the colors function to get those values.

> What is also interesting, prompt can output all colors defined by "number"
> instead of a color name. e.g. 1 for red 9 for bright-red ...

Exactly, which is why you can use $color[grey] or
$color[bg-bright-red] to get a number.  But that number is the same
for grey and gray as $color[black].