Skip to content
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
Closed

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

Walther opened this issue May 14, 2014 · 17 comments
Labels
Milestone

Comments

@Walther
Copy link

@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
Copy link

@codeincontext 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
Copy link

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

@codeincontext
Copy link

@codeincontext 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
Copy link

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

@codeincontext
Copy link

@codeincontext 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
Copy link

@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
@brentropy
Copy link

@brentropy brentropy 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
Copy link

@jaspernbrouwer 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
Copy link

@purpleKarrot purpleKarrot commented Nov 2, 2015

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

@codeincontext
Copy link

@codeincontext 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
Copy link
Contributor

@pickfire 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
Copy link

@jaspernbrouwer 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
Copy link
Contributor

@pickfire 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
Copy link
Author

@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
Copy link
Contributor

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

ridiculousfish added a commit that referenced this issue Dec 9, 2015
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
Copy link
Contributor

@krader1961 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
Copy link
Member

@ridiculousfish ridiculousfish commented Dec 31, 2015

Closing. Thanks krader!

@faho faho modified the milestones: next-2.x, fish-future Feb 5, 2016
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants
You can’t perform that action at this time.