New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

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

@codeincontext

This comment has been minimized.

Show comment
Hide comment
@codeincontext

codeincontext Jan 8, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@ghost

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

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.

@codeincontext

This comment has been minimized.

Show comment
Hide comment
@codeincontext

codeincontext Jan 8, 2015

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.

codeincontext commented Jan 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ghost

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

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?

@codeincontext

This comment has been minimized.

Show comment
Hide comment
@codeincontext

codeincontext Jan 8, 2015

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

codeincontext commented Jan 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ghost

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

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

This comment has been minimized.

Show comment
Hide comment
@brentburg

brentburg Jan 31, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@jaspernbrouwer

jaspernbrouwer May 25, 2015

+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 commented May 25, 2015

+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

This comment has been minimized.

Show comment
Hide comment
@purpleKarrot

purpleKarrot Nov 2, 2015

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

purpleKarrot commented Nov 2, 2015

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

@codeincontext

This comment has been minimized.

Show comment
Hide comment
@codeincontext

codeincontext Nov 2, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@pickfire

pickfire Nov 3, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@jaspernbrouwer

jaspernbrouwer Nov 3, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@pickfire

pickfire Nov 3, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@Walther

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

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

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Nov 24, 2015

Contributor

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.

Contributor

krader1961 commented Nov 24, 2015

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 added a commit to krader1961/fish-shell that referenced this issue Nov 24, 2015

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.

krader1961 added a commit to krader1961/fish-shell that referenced this issue Nov 24, 2015

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.

krader1961 added a commit to krader1961/fish-shell that referenced this issue Nov 24, 2015

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.

krader1961 added a commit to krader1961/fish-shell that referenced this issue Nov 24, 2015

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.

ridiculousfish added a commit that referenced this issue Dec 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Dec 31, 2015

Contributor

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

Contributor

krader1961 commented Dec 31, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Dec 31, 2015

Member

Closing. Thanks krader!

Member

ridiculousfish commented Dec 31, 2015

Closing. Thanks krader!

@faho faho modified the milestones: 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