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

Closed
Walther opened this Issue May 14, 2014 · 17 comments

Projects

None yet

10 participants

@Walther
Walther commented May 14, 2014

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:
image

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)

@ridiculousfish ridiculousfish added this to the fish-future milestone Nov 2, 2014
@skattyadz

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
ghost commented Jan 8, 2015

@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.

@skattyadz

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

screen shot 2015-01-08 at 15 04 30

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
ghost commented Jan 8, 2015

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?

@skattyadz

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

screen shot 2015-01-08 at 16 46 04

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

@ghost
ghost commented Jan 8, 2015

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.

@zanchey zanchey added the enhancement label Jan 19, 2015
@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.

@tannhuber tannhuber referenced this issue in oh-my-fish/oh-my-fish-legacy Feb 9, 2015
Closed

Budspencer Colors Working in Tmux only? #359

@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?

@skattyadz

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
Contributor
pickfire commented Nov 3, 2015

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.

@pickfire
Contributor
pickfire commented Nov 3, 2015

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
Walther commented Nov 3, 2015

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
Member

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 krader1961 added a commit to krader1961/fish-shell that referenced this issue Nov 24, 2015
@krader1961 krader1961 add support for ANSI "bright" colors
This adds support for the ANSI x3.64 "bright" colors in the basic sixteen
color palette. This is especially useful when trying to use the base colors
as a background color. The "bright" variants tend to be more useful as
background colors compared to the non-bright variants.

This also fixes a bug in so far as palette number 7 is actually grey and
not white whereas palette number 15 is white. At least on the terminal
emulators on which I've tested this change (Ubuntu xterm & uxterm, Mac
OS X Terminal & iTerm2).

Resolves issue #1464.
a80bd7a
@krader1961 krader1961 added a commit to krader1961/fish-shell that referenced this issue Nov 24, 2015
@krader1961 krader1961 add support for ANSI "bright" colors
This adds support for the ANSI x3.64 "bright" colors in the basic sixteen
color palette. This is especially useful when trying to use the base colors
as a background color. The "bright" variants tend to be more useful as
background colors compared to the non-bright variants.

This also fixes a bug in so far as palette number 7 is actually grey and
not white whereas palette number 15 is white. At least on the terminal
emulators on which I've tested this change (Ubuntu xterm & uxterm, Mac
OS X Terminal & iTerm2).

Resolves issue #1464.
dac59f3
@krader1961 krader1961 added a commit to krader1961/fish-shell that referenced this issue Nov 24, 2015
@krader1961 krader1961 add support for ANSI "bright" colors
This adds support for the ANSI x3.64 "bright" colors in the basic sixteen
color palette. This is especially useful when trying to use the base colors
as a background color. The "bright" variants tend to be more useful as
background colors compared to the non-bright variants.

This also fixes a bug in so far as palette number 7 is actually grey and
not white whereas palette number 15 is white. At least on the terminal
emulators on which I've tested this change (Ubuntu xterm & uxterm, Mac
OS X Terminal & iTerm2).

Resolves issue #1464.
bcb7353
@krader1961 krader1961 added a commit to krader1961/fish-shell that referenced this issue Nov 24, 2015
@krader1961 krader1961 add support for ANSI "bright" colors
This adds support for the ANSI x3.64 "bright" colors in the basic sixteen
color palette. This is especially useful when trying to use the base colors
as a background color. The "bright" variants tend to be more useful as
background colors compared to the non-bright variants.

This also fixes a bug in so far as palette number 7 is actually grey and
not white whereas palette number 15 is white. At least on the terminal
emulators on which I've tested this change (Ubuntu xterm & uxterm, Mac
OS X Terminal & iTerm2).

Resolves issue #1464.
598d6db
@ridiculousfish ridiculousfish added a commit that referenced this issue Dec 9, 2015
@krader1961 @ridiculousfish krader1961 + ridiculousfish add support for ANSI "bright" colors
This adds support for the ANSI x3.64 "bright" colors in the basic sixteen
color palette. This is especially useful when trying to use the base colors
as a background color. The "bright" variants tend to be more useful as
background colors compared to the non-bright variants.

This also fixes a bug in so far as palette number 7 is actually grey and
not white whereas palette number 15 is white. At least on the terminal
emulators on which I've tested this change (Ubuntu xterm & uxterm, Mac
OS X Terminal & iTerm2).

Resolves issue #1464.
0a0acc8
@krader1961
Member

@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
Member

Closing. Thanks krader!

@faho faho modified the milestone: next-2.x, fish-future Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment