What appears to be inconsistent results from ${(%):-%F{${subscript}}

What appears to be inconsistent results from ${(%):-%F{${subscript}}

[Jim]

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

Hi all,

Output for the  following function will help visualize what I believe to be
inconsistencies of the output of ${(%):-%F{${subscript}}.
I would assume %B (background) would yield similar results.

Note the function outputs a solid block character in color.
Hopefully the block charcter will cut and paste correctly.

color_conversion_check () {
  local subscript colorconversion
  local subscripts
  subscripts=(black blue cyan default gray green grey magenta red white
yellow
  bright-blue bright-cyan bright-gray bright-green bright-grey
bright-magenta
  bright-red bright-white bright-yellow
  0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
  16 17 18 229 230 231
  232 233 234 253 254 255
  '#000000' '#007fff' '#ff0080' '#abcdef' '#007FFF' '#FF0080' '#ABCDEF'
  )
  print -- "Output of fg associative array"
  print --  "${fg[gray]}${(r.24..█.)}\e[0m  ${(V)fg[gray]}  fg[gray]"
  print --  "${fg[grey]}${(r.24..█.)}\e[0m  ${(V)fg[grey]}  fg[grey]"
  print --
  for subscript ($subscripts) {
    colorconversion="${(%):-%F{${subscript}}"
    print -- "${(%)colorconversion}${(r.24..█.)}\e[0m
 ${(V)colorconversion}  ${subscript}"
  }
}

First, '${(%):-%F{${subscript}}' has unbalanced curly brackets({}), but
still works.
Adding a closing bracket(}) results in '}' being added to the output. So
instead of
getting ',,,m' you get '...m}'.  I'm confused. What am I missing?

To my original point

1)  the color names grey and gray do not output black but output the default

2) bright color names are not converted but output the default color
    Should bright color names be added to the code?
  As you can see in 3) the code for bright colors is there

3) using decimal numbers(0-255)
    0 - 15  uses 30-27 and 90-97(bright) instead of using the colors defined
   by the terminal
  NOTE: 0-15 are defined even for TERM=linux
  16-255 uses the colors defined by the terminal
  Is there a reason why it doesn't use the terminal colors for 0-15?

Hex codes appear to work as expected.

Regards,

Jim Murphy

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

Re: What appears to be inconsistent results from ${(%):-%F{${subscript}}

[Jim]

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

Type-o

On Mon, Mar 4, 2024 at 8:56 AM Jim <linux.tech.guy@gmail.com> wrote:

>
> 3) using decimal numbers(0-255)
>     0 - 15  uses 30-27 and 90-97(bright) instead of using the colors
> defined
>
>
Should read 30-37

Sorry,

Jim

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

Re: What appears to be inconsistent results from ${(%):-%F{${subscript}}

[Mikael Magnusson]

On 3/4/24, Jim <linux.tech.guy@gmail.com> wrote:
> Hi all,
>
> Output for the  following function will help visualize what I believe to be
> inconsistencies of the output of ${(%):-%F{${subscript}}.
> I would assume %B (background) would yield similar results.
>
> Note the function outputs a solid block character in color.
> Hopefully the block charcter will cut and paste correctly.
>
> color_conversion_check () {
>   local subscript colorconversion
>   local subscripts
>   subscripts=(black blue cyan default gray green grey magenta red white
> yellow
>   bright-blue bright-cyan bright-gray bright-green bright-grey
> bright-magenta
>   bright-red bright-white bright-yellow
>   0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
>   16 17 18 229 230 231
>   232 233 234 253 254 255
>   '#000000' '#007fff' '#ff0080' '#abcdef' '#007FFF' '#FF0080' '#ABCDEF'
>   )
>   print -- "Output of fg associative array"
>   print --  "${fg[gray]}${(r.24..█.)}\e[0m  ${(V)fg[gray]}  fg[gray]"
>   print --  "${fg[grey]}${(r.24..█.)}\e[0m  ${(V)fg[grey]}  fg[grey]"
>   print --
>   for subscript ($subscripts) {
>     colorconversion="${(%):-%F{${subscript}}"
>     print -- "${(%)colorconversion}${(r.24..█.)}\e[0m
>  ${(V)colorconversion}  ${subscript}"
>   }
> }
>
> First, '${(%):-%F{${subscript}}' has unbalanced curly brackets({}), but
> still works.
> Adding a closing bracket(}) results in '}' being added to the output. So
> instead of
> getting ',,,m' you get '...m}'.  I'm confused. What am I missing?

This is a common-ish pitfall. When in double quotes, { and } are not
special to the shell, so the first } matches the opening { from ${.
You then have an extraneous } which is printed as normal.

> To my original point
>
> 1)  the color names grey and gray do not output black but output the
> default

The available colors are: black, red, green, yellow, blue, magenta,
cyan and white.

> 2) bright color names are not converted but output the default color
>     Should bright color names be added to the code?

ANSI only guarantees 8 colors are available.

> 3) using decimal numbers(0-255)
>     0 - 15  uses 30-27 and 90-97(bright) instead of using the colors
> defined
>    by the terminal
>   NOTE: 0-15 are defined even for TERM=linux
>   16-255 uses the colors defined by the terminal
>   Is there a reason why it doesn't use the terminal colors for 0-15?

I have no idea what you mean by this.

-- 
Mikael Magnusson

Re: What appears to be inconsistent results from ${(%):-%F{${subscript}}

[Bart Schaefer]

In addition to what Mikael already said ...

On Mon, Mar 4, 2024 at 6:56 AM Jim <linux.tech.guy@gmail.com> wrote:
>
> First, '${(%):-%F{${subscript}}' has unbalanced curly brackets({}), but still works.

Because of the "}" effect Mikael described, the prompt expansion here
will be for e.g. "%F{grey" with end-of string instead of closing
brace.  That happens to work.

>  colorconversion="${(%):-%F{${subscript}}"

You need another set of quotes here, e.g.,

   colorconversion="${(%):-"%F{${subscript}}"}"

Double-quotes can be nested when they are inside a nested parameter expansion.

> 1)  the color names grey and gray do not output black but output the default

For the Nth time, prompt expansion does not correspond to the names
instantiated by the "colors" function.  The "colors" names are for
generating direct output to the terminal, not for populating prompt
strings.

> using decimal numbers(0-255)
>     0 - 15  uses 30-27 and 90-97(bright) instead of using the colors defined
>    by the terminal
> Hex codes appear to work as expected.

     [...] by a sequence in braces following
     the %F, for example %F{red}.  In the latter case the values allowed
     are as described for the fg zle_highlight attribute; *note
     Character Highlighting::.

Numbers 0-7 are interpreted as the names "black","red",...,"white"
Numbers 8-(terminfo maxcolor) are interpreted as the color defined by terminfo
Numbers greater than that are the colors defined by the terminal itself

So the only reliable thing for true-color terminals is to use the hex
codes.  This is not really clearly explained under "Character
Highlighting".

Re: What appears to be inconsistent results from ${(%):-%F{${subscript}}

[Oliver Kiddle]

Jim wrote:
> Output for the  following function will help visualize what I believe to be
> inconsistencies of the output of ${(%):-%F{${subscript}}.

The escape sequences generated for %F, %K, etc come from the system
termcap database. So the output produced by your function will vary for
different systems and terminals. This makes it difficult to understand
what it is you regard to be inconsistent. For some terminals, the
colours 0 - 255 result in consistent escape sequences running from
\e[38;5;0m through to \e[38;5;255m

Check what the AF termcap (or setab terminfo) entry is for your
terminal:
  od -a <<<$termcap[AF]
or some other terminal:
  TERM=foot zsh -c 'od -a <<<$termcap[AF]'

This string (which is processed by tparm()) may contain conditionals
and amounts to a stack based byte-code. It is not uncommon that this
interface will generate \e[32m for colour 2 (green), \e[92m for colour
10 (bright green) but \e[38;5;82m for colour 82. Perhaps this is what
you are seeing as inconsistent. The termcap/terminfo interface only
accepts a single number as the parameter for this entry.

> To my original point
>
> 1)  the color names grey and gray do not output black but output the default

grey/gray is not one of the eight original colours supported by a
terminal that supports eight colours. Terminals that support 16 colours
added 8 bright variants. bright-black and bright-white is fairly
meaningless so in practice, "white" was often somewhat off-white and
bright-black is what might be better termed "grey".

> 2) bright color names are not converted but output the default color
>     Should bright color names be added to the code?
>   As you can see in 3) the code for bright colors is there

Unrecognised values select the default color. My own opinion is that
it would be better not to try to recognise more colour names because
it'd just lead to more complaints about names not matching colours.
Also, grey has two valid spellings and "bright" amounts to technical
terminology that is only meaningful with the context of historical
terminal colours. TERM=linux may support colours 0-15 but not all
terminals do.

> 3) using decimal numbers(0-255)
>     0 - 15  uses 30-27 and 90-97(bright) instead of using the colors defined
>    by the terminal
>   NOTE: 0-15 are defined even for TERM=linux
>   16-255 uses the colors defined by the terminal
>   Is there a reason why it doesn't use the terminal colors for 0-15?

I'm suspecting from this last sentence that, in the interests of making
a wider range of colours available, your terminal is producing different
colours for different forms. So perhaps \e[92m is a bright green and
\e[38;5;10m is something else. For the termcap interface, there can only
be one colour 10. Hard coding escape sequences in zsh should be avoided
if at all possible. If you really want a wide-choice of colours, most
newer graphical terminals support true-colour. (Though some of them fake
it in the interests of keeping memory usage for the scroll-back buffer
down. And others just consume lots...)

Oliver