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

Shouldn't g:terminal_color_* follow NR-16? #105

Open
m00qek opened this issue Oct 6, 2021 · 5 comments
Open

Shouldn't g:terminal_color_* follow NR-16? #105

m00qek opened this issue Oct 6, 2021 · 5 comments
Labels
workaround The issue can be addressed using a workaround

Comments

@m00qek
Copy link

m00qek commented Oct 6, 2021

First of all, thanks for creating/maintaining this theme. It is really good :)

I'm confused if this should set g:terminal_color_* using NR-16 or NR-8. From :help terminal-config

TERMINAL COLORS

The `{g,b}:terminal_color_x` variables control the terminal color palette,
where `x` is the color index between 0 and 255 inclusive.  The variables are
read during |TermOpen|. The value must be a color name or hexadecimal string.
Example: >
    let g:terminal_color_4 = '#ff0000'
    let g:terminal_color_5 = 'green'
Only works for RGB UIs (see 'termguicolors'); for 256-color terminals the
color index is just forwarded.

From this I understand that this override will work up to g:terminal_color_255 but it does not clarify which standard should be used. Looking at :help cterm-color

							*cterm-colors*
	    NR-16   NR-8    COLOR NAME ~
	    0	    0	    Black
	    1	    4	    DarkBlue
	    2	    2	    DarkGreen
	    3	    6	    DarkCyan
	    4	    1	    DarkRed
	    5	    5	    DarkMagenta
	    6	    3	    Brown, DarkYellow
	    7	    7	    LightGray, LightGrey, Gray, Grey
	    8	    0*	    DarkGray, DarkGrey
	    9	    4*	    Blue, LightBlue
	    10	    2*	    Green, LightGreen
	    11	    6*	    Cyan, LightCyan
	    12	    1*	    Red, LightRed
	    13	    5*	    Magenta, LightMagenta
	    14	    3*	    Yellow, LightYellow
	    15	    7*	    White

	The number under "NR-16" is used for 16-color terminals ('t_Co'
	greater than or equal to 16).  The number under "NR-8" is used for
	8-color terminals ('t_Co' less than 16).  The '*' indicates that the
	bold attribute is set for ctermfg.  In many 8-color terminals (e.g.,
	"linux"), this causes the bright colors to appear.  This doesn't work
	for background colors!	Without the '*' the bold attribute is removed.
	If you want to set the bold attribute in a different way, put a
	"cterm=" argument AFTER the "ctermfg=" or "ctermbg=" argument.	Or use
	a number instead of a color name.

	Note that for 16 color ansi style terminals (including xterms), the
	numbers in the NR-8 column is used.  Here '*' means 'add 8' so that Blue
	is 12, DarkGray is 8 etc.

	Note that for some color terminals these names may result in the wrong
	colors!

I see that the standard chosen will change colors a lot since, for example, the color red can be in position 4 or 1 depending on what was used. Anyway, I think colors from 8 to 15 should use brighter versions instead of just using the same ones as the first eight. WDYT?

@sainnhe
Copy link
Owner

sainnhe commented Oct 6, 2021

Because I haven't designed a brighter palette yet, and currently there is no plan to do so.

@carlosala
Copy link

carlosala commented Nov 2, 2021

Would be really, really great to have that brighter pallette. I encourage you to do it! Btw, really great colorscheme, I switched from regular gruvbox and I'm in love with it.
And there are only 6 colors missing, as bright dark and white are done I think.

@hurricanehrndz
Copy link

Using the existing colors I believe the terminal color set should be as follows:
image

@carlosala
Copy link

Using the existing colors I believe the terminal color set should be as follows:
image

Actually 8 coincides with 0 and 15 with 7, we don't have bright black and bright white, I think

@antoineco
Copy link
Collaborator

As sainnhe mentionned, there is no bright palette in this colorscheme to refer to. However, it is possible to apply a shade to the existing 0-7 colors to get brighter 8-15 colors: #152 (comment)

@antoineco antoineco added the workaround The issue can be addressed using a workaround label Apr 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
workaround The issue can be addressed using a workaround
Projects
None yet
Development

No branches or pull requests

5 participants