* prompt colors bug? also possible feature add @ 2023-08-17 22:18 Jim 2023-08-17 23:23 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Jim @ 2023-08-17 22:18 UTC (permalink / raw) To: devs [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: prompt colors bug? also possible feature add 2023-08-17 22:18 prompt colors bug? also possible feature add Jim @ 2023-08-17 23:23 ` Bart Schaefer 2023-08-23 0:37 ` Jim 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2023-08-17 23:23 UTC (permalink / raw) To: linuxtechguy; +Cc: devs 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) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: prompt colors bug? also possible feature add 2023-08-17 23:23 ` Bart Schaefer @ 2023-08-23 0:37 ` Jim 2023-08-23 4:20 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Jim @ 2023-08-23 0:37 UTC (permalink / raw) To: Bart Schaefer; +Cc: devs [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: prompt colors bug? also possible feature add 2023-08-23 0:37 ` Jim @ 2023-08-23 4:20 ` Bart Schaefer 2023-08-23 12:42 ` Jim 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2023-08-23 4:20 UTC (permalink / raw) To: linuxtechguy; +Cc: devs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: prompt colors bug? also possible feature add 2023-08-23 4:20 ` Bart Schaefer @ 2023-08-23 12:42 ` Jim 2023-08-24 3:45 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Jim @ 2023-08-23 12:42 UTC (permalink / raw) To: Bart Schaefer; +Cc: devs [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: prompt colors bug? also possible feature add 2023-08-23 12:42 ` Jim @ 2023-08-24 3:45 ` Bart Schaefer 2023-09-20 1:15 ` Jim 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2023-08-24 3:45 UTC (permalink / raw) To: linuxtechguy; +Cc: devs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: prompt colors bug? also possible feature add 2023-08-24 3:45 ` Bart Schaefer @ 2023-09-20 1:15 ` Jim 2023-09-20 1:56 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Jim @ 2023-09-20 1:15 UTC (permalink / raw) To: Bart Schaefer; +Cc: devs [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: prompt colors bug? also possible feature add 2023-09-20 1:15 ` Jim @ 2023-09-20 1:56 ` Bart Schaefer 0 siblings, 0 replies; 8+ messages in thread From: Bart Schaefer @ 2023-09-20 1:56 UTC (permalink / raw) To: linuxtechguy; +Cc: devs 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]. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-09-20 1:57 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-08-17 22:18 prompt colors bug? also possible feature add Jim 2023-08-17 23:23 ` Bart Schaefer 2023-08-23 0:37 ` Jim 2023-08-23 4:20 ` Bart Schaefer 2023-08-23 12:42 ` Jim 2023-08-24 3:45 ` Bart Schaefer 2023-09-20 1:15 ` Jim 2023-09-20 1:56 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).