set_color can't use all "ANSI" colors on background

[Walther]

I've been trying to create a somewhat dynamic theme, that would instead of hardcoded hex values refer to the terminal's own "ANSI" colors.

However, it isn't possible to use a bold/bright variant (the latter 8 of the 16 palette) as a background color with set_color.

Screenshot example:

Expected results: the "bold/bright" variant of green should be the backround color in the third and fourth line. Instead, third line does not work at all, and fourth results in bold/bright foreground and the background is the "normal" green.

On foreground (the first line), it is possible to access the "bold/bright" variants of ANSI colors specified by the terminal.

Suggestion: allow referring to "ANSI" colors with color0-color15 or something similar, instead of relying to -o / --bold, or alternatively, allow -o / --bold parsing also for the background colors.

(spacecolors.sh borrowed with <3 from here)

[codeincontext]

This same thing just tripped me up. I'm using a base16 color scheme which stores additional colors I want to use in the 'bright' palette

[codeincontext]

This same thing just tripped me up. I'm using a base16 color scheme which stores additional colors I want to use in the 'bright' palette

[ghost]

@skattyadz Hi. You too want to use the bright palette for background colors?

Could this be done using tput setaf perhaps? I would like to know too.

[ghost]

@skattyadz Hi. You too want to use the bright palette for background colors?

Could this be done using tput setaf perhaps? I would like to know too.

[codeincontext]

If you look at the image below you'll see that my terminal color scheme stores some custom colors in the 8-15 range. I'd like to be able to use these colors in my prompt

I'm sure it's a rare use case, but wanted maintainers to know that being able to specify by color12 etc does have value for some people.

[codeincontext]

If you look at the image below you'll see that my terminal color scheme stores some custom colors in the 8-15 range. I'd like to be able to use these colors in my prompt

I'm sure it's a rare use case, but wanted maintainers to know that being able to specify by color12 etc does have value for some people.

[ghost]

Mmm, I see. It is not about your terminal supporting these colors, because you could always echo (set_color -b bf616a) " " or whatever, but about retrieving the colors between 8~9 stored by your terminal scheme palette. Correct?

Question. How can you access the other colors without specifying the hex value?

[ghost]

Mmm, I see. It is not about your terminal supporting these colors, because you could always echo (set_color -b bf616a) " " or whatever, but about retrieving the colors between 8~9 stored by your terminal scheme palette. Correct?

Question. How can you access the other colors without specifying the hex value?

[codeincontext]

As far as I know, supplying a hex code will make fish pick the closest of the 240 colors it knows about. eg:

At the moment to get bf616a I would do set_color -b red

[codeincontext]

As far as I know, supplying a hex code will make fish pick the closest of the 240 colors it knows about. eg:

At the moment to get bf616a I would do set_color -b red

[ghost]

Ah, I see. The terminal scheme stores the color codes in Fish color variables.

As far as I know, supplying a hex code will make fish pick the closest of the 240 colors it knows about.

Yes, this is correct.

[ghost]

Ah, I see. The terminal scheme stores the color codes in Fish color variables.

As far as I know, supplying a hex code will make fish pick the closest of the 240 colors it knows about.

Yes, this is correct.

[brentburg]

I am having the same issue. Would love to be able to reference colors by number so I can use colors 8-15 from my base16 theme as a background.

[brentburg]

I am having the same issue. Would love to be able to reference colors by number so I can use colors 8-15 from my base16 theme as a background.

[jaspernbrouwer]

+1

I would opt for ditching the -o / --bold arguments completely and append the list of color names with "bright" versions:

• black / brblack
• red / brred
• green / brgreen
• yellow / bryellow
• blue / brblue
• magenta / brmagenta
• cyan / brcyan
• white / brwhite
• (normal)

That should ease the implementation of full ANSI palette support a lot, as you won't need to figure out how to literary combine --bold and --background.

[jaspernbrouwer]

+1

I would opt for ditching the -o / --bold arguments completely and append the list of color names with "bright" versions:

• black / brblack
• red / brred
• green / brgreen
• yellow / bryellow
• blue / brblue
• magenta / brmagenta
• cyan / brcyan
• white / brwhite
• (normal)

That should ease the implementation of full ANSI palette support a lot, as you won't need to figure out how to literary combine --bold and --background.

[purpleKarrot]

I have the same issue. Is the use case of using base16 really so rare?

[purpleKarrot]

I have the same issue. Is the use case of using base16 really so rare?

[codeincontext]

I moved to neovim so this isn't an issue for me any more

— adam

On Mon, Nov 2, 2015 at 11:37 AM, Daniel Pfeifer notifications@github.com
wrote:

I have the same issue. Is the use case of using base16 really so rare?

Reply to this email directly or view it on GitHub:
#1464 (comment)

[codeincontext]

I moved to neovim so this isn't an issue for me any more

— adam

On Mon, Nov 2, 2015 at 11:37 AM, Daniel Pfeifer notifications@github.com
wrote:

I have the same issue. Is the use case of using base16 really so rare?

Reply to this email directly or view it on GitHub:
#1464 (comment)

[pickfire]

I use base16 but I doesn't found any problem with it. I also uses neovim but I hate that it's colors is a bit different from the 256 colors.

If I recall correctly, fish can use true colors. Try set_color 1F1F1F but I am not sure how to check if the colors are correct with gimp.

[pickfire]

I use base16 but I doesn't found any problem with it. I also uses neovim but I hate that it's colors is a bit different from the 256 colors.

If I recall correctly, fish can use true colors. Try set_color 1F1F1F but I am not sure how to check if the colors are correct with gimp.

[jaspernbrouwer]

If I recall correctly, fish can use true colors. Try set_color 1F1F1F but I am not sure how to check if the colors are correct with gimp.

That only works when the terminal (or emulator) supports true colors.

[jaspernbrouwer]

If I recall correctly, fish can use true colors. Try set_color 1F1F1F but I am not sure how to check if the colors are correct with gimp.

That only works when the terminal (or emulator) supports true colors.

[pickfire]

That only works when the terminal (or emulator) supports true colors.

That's true, of course I am using a terminal that support true colors. Nowdays, a lot of terminal support true colors. You could look at: https://gist.github.com/XVilka/8346728

[pickfire]

That only works when the terminal (or emulator) supports true colors.

That's true, of course I am using a terminal that support true colors. Nowdays, a lot of terminal support true colors. You could look at: https://gist.github.com/XVilka/8346728

[Walther]

See on Wikipedia - ANSI color standard specifies a possibility of 16-color palette, of which all colors should be referrable whether as foreground or background colors, i.e. there is a distinction between foreground/background and normal/bold.

I think "true color" support is irrelevant, as the usage of relative color palette allows for a unified look between CLI applications without explicit manual theming.

[Walther]

See on Wikipedia - ANSI color standard specifies a possibility of 16-color palette, of which all colors should be referrable whether as foreground or background colors, i.e. there is a distinction between foreground/background and normal/bold.

I think "true color" support is irrelevant, as the usage of relative color palette allows for a unified look between CLI applications without explicit manual theming.

[krader1961]

I prefer a prompt where each segment (e.g., hostname, git branch name) uses a distinct background color as it stands out more clearly against the colored output of other commands like ls. And for that use case the "bright" variants in the basic 16 color palette are much more useful. In zsh (which I'm migrating from) I had my own color management mechanism where the primary eight colors had variants prefixed by "l_" (for "light"). But I like @jaspernbrouwer's proposal (e.g., "brcyan"). This involves a trivial change to the named_colors table in colors.cpp.

Also, the current table is incorrect in assigning the label "white" to palette entry 7 which is actually light grey. Palette entry 15 is white.

I'm ambivalent about adding support for referencing all palette entries by index using a scheme like colorN. I did implement it in my zsh color subsystem but found that I never use it so I'm not motivated to implement it. However, if someone else provides a change that implements it with minimal additional complexity I don't see any reason to object.

[krader1961]

I prefer a prompt where each segment (e.g., hostname, git branch name) uses a distinct background color as it stands out more clearly against the colored output of other commands like ls. And for that use case the "bright" variants in the basic 16 color palette are much more useful. In zsh (which I'm migrating from) I had my own color management mechanism where the primary eight colors had variants prefixed by "l_" (for "light"). But I like @jaspernbrouwer's proposal (e.g., "brcyan"). This involves a trivial change to the named_colors table in colors.cpp.

Also, the current table is incorrect in assigning the label "white" to palette entry 7 which is actually light grey. Palette entry 15 is white.

I'm ambivalent about adding support for referencing all palette entries by index using a scheme like colorN. I did implement it in my zsh color subsystem but found that I never use it so I'm not motivated to implement it. However, if someone else provides a change that implements it with minimal additional complexity I don't see any reason to object.

[krader1961]

@Walther, or anyone else who has commented on this issue, can this be closed? The change I made to support the "bright" variants has been merged and is working for me. If someone feels strongly about adding support for referencing the 256 color palette by index I think a new issue should be opened by someone willing to write the code to implement it.

[krader1961]

@Walther, or anyone else who has commented on this issue, can this be closed? The change I made to support the "bright" variants has been merged and is working for me. If someone feels strongly about adding support for referencing the 256 color palette by index I think a new issue should be opened by someone willing to write the code to implement it.

[ridiculousfish]

Closing. Thanks krader!

[ridiculousfish]

Closing. Thanks krader!