Color assignment in st-term is off.

[Interesting-name]

Two problems with the vim colorscheme nord-vim and st:

1. Comments are the same color as the background.
2. In visual mode, colors do not change to indicate the selection.

More detailed description:
After starting to use regolith-linux, I wanted to apply the nord colorscheme (current default) to every part of my workflow. I thus installed nord-vim. Unfortunately, I then noticed that comments were invisible while using vim in combination with st and the visual mode selection did not change any colors. I tried in gnome-terminal and everything is fine here. The problem must thus lie with st's colors.

A possible solution for no. 1:
The color used for the background in st-term is St.color0: color_base03. The color vim uses for comments is defined in the st-term file as St.color8: color_base03.

I think line 10 in regolith-styles/Xresources/st-term should read St.color8: color_base00 instead of St.color8: color_base03. After this change, comments are visible as usual. I'm not sure if this will mess with other parts of st's colors, but so far it seems that all is well.

I don't know about the selection problem, although I noticed a difference between gnome-terminal and st when using neofetch, see attached picture. The colors displayed are colors 0 through 15 of the terminals color palette.

Note that I already changed St.color8 to color_base00 before taking the screenshot. Thus color 8 is the same for both st and gnome-terminal here.

[kgilmer]

Thank you for the detailed bug report @Interesting-name 😄 .

I've made the Xresource change you've suggested and don't see any problems. I noticed I had to specify command-line options to neofetch to display 16 colors: neofetch --block_range 0 15

Regarding the selection issue, I installed nord-vim and am able to see selection in visual mode. Am I missing something?

[kgilmer]

I think line 10 in regolith-styles/Xresources/st-term should read St.color8: color_base00 instead of St.color8: color_base03.

Out of curiosity, how did you come to color_base00?

[Interesting-name]

@kgilmer

I noticed I had to specify command-line options to neofetch to display 16 colors: neofetch --block_range 0 15

Ah yes, I should have mentioned that, sorry!

Regarding the selection issue, I installed nord-vim and am able to see selection in visual mode. Am I missing something?

Are you using vim's visual mode (enter with V and then move the cursor to select) or just selecting parts of the text with the mouse? Because the latter also works for me. It's just vim's visual mode that doesn't work.

Out of curiosity, how did you come to color_base00?

Well, I visually compared vim's text color running in gnome-terminal with the colors given on the nord theme website. Then I looked up which colors were assigned to which Xresources variables. (I also noticed that you changed color_base00 for better contrast 😄)

[kgilmer]

Ah, ok I see what you mean about Visual Mode.

[Interesting-name]

Hey @kgilmer, I just tested assigning the exact same color palette to st terminal as i had in gnome-terminal (see screenshot in the OP). I did not change St.color0, since for some reason this also changes the terminal background. Then, ~/.Xresources.d/st-term reads:

St.font:              typeface_terminal
St.color0:            color_base03
St.color1:            color_red
St.color2:            color_green
St.color3:            color_yellow
St.color4:            color_blue
St.color5:            color_violet
St.color6:            color_cyan
St.color7:            color_base1
St.color8:            color_base00
St.color9:            color_red
St.color10:           color_green
St.color11:           color_yellow
St.color12:           color_blue
St.color13:           color_violet
St.color14:           color_cyan
St.color15:           color_base1

This of course eliminates most of the discrepancies between the colors in st and gnome-terminal.
The problem is, that the background is assigned the same color as palette color 0.

More details:
I think st currently takes it's background color from St.color0, which is set as color_base03. The value of palette color 0 should be color_base02, though, while the background color remains color_base03.

Now it seems that it's impossible to change st's background color without compiling it (?).
Unfortunately I am way out of my depth here, maybe you could comment on how to fix this?
I found this ArchWiki entry on how to change st's colors, but I am unsure on how and where to implement the changes.

By the way, should I open a new issue for this (e.g. in regolith-st) or do you prefer to keep all the color assignment stuff here?

[leosunmo]

I have a very good Nord colour palette for Alacritty from https://github.com/arcticicestudio/nord-alacritty and I've been bad and have not converted it to our Xresources scheme. I will try to do that as part of the base16 colour work. My config is

# Colors (Nord)
colors:
   # Default colors
  primary:
    background: '0x2E3440'
    foreground: '0xD8DEE9'

  # Normal colors
  normal:
    black:   '0x3B4252'
    red:     '0xBF616A'
    green:   '0xA3BE8C'
    yellow:  '0xEBCB8B'
    blue:    '0x81A1C1'
    magenta: '0xB48EAD'
    cyan:    '0x88C0D0'
    white:   '0xE5E9F0'

  # Bright colors
  bright:
    black:   '0x4C566A'
    red:     '0xBF616A'
    green:   '0xA3BE8C'
    yellow:  '0xEBCB8B'
    blue:    '0x81A1C1'
    magenta: '0xB48EAD'
    cyan:    '0x8FBCBB'
    white:   '0xECEFF4'

which looks great and works very well with Vim.

I reckon this should stay in Styles repo as it's something we have to sort as part of the Xresources/Xresources-base16 stuff.

[kgilmer]

@leosunmo can you confirm that the issue above w/ Visual Mode does not occur w/ your Alacritty theme? Any thoughts on why st would be having this trouble?

[Interesting-name]

Hey @kgilmer,

Any thoughts on why st would be having this trouble?

As I mentioned above, this is because st takes its background color from St.color0 instead of having it defined outside of the usual palette.

Compare the definiton of the nord colors in my example with those in @leosunmo's alacritty colorscheme. In the st version, there is no definition of background/foreground, only the 16 palette colors.

[leosunmo]

Vim visual mode is fine in my terminal. I think what @Interesting-name is saying makes sense. I'll have a look and see if there's something we can do to easily fix it.

[nordmagnus999]

I noticed the same thing @Interesting-name noticed while i was trying to replicate st color-scheme (with the default nord styles) to urxvt.
I did some more digging and i think it is because of one of the patch regolith apply to st (namely the one called st-no_bold_colors-20170623-b331da5.diff)
Could be wrong, but its the only thing i could think of.

[nordmagnus999]

St doesn't use xterm so it was a bit confusing to know what happened there, so i started to comment each lines related to the used color-scheme for st, and the terminal i wanted to use the same color-scheme on, urxvt. (since its Xresources, i had to put a ! on each beginning line).

I then used neofetch like @Interesting-name did and noticed st did used diff colors without any color-scheme used by default, compared to urxvt, which default to normal xterm colors (white background etc)
Jut putting this here in case you wanted to reproduce it/wanted to know how i came up to that conclusion.

[Interesting-name]

@kgilmer, @leosunmo, @nordmagnus999

Quick heads-up: I noticed that setting St.background in ~/.Xresources.d/st-term (copy of regolith-styles/Xresources/st-term) changes the cursor color (and nothing else).

I hope this helps identify the source of the problem!

[nordmagnus999]

Yeah, i noticed the same thing too :) @Interesting-name
I'm 99% sure the problem here come from the st-no_bold_colors-20170623-b331da5.diff patch regolith use on st, at least from my own testing.

[Interesting-name]

@kgilmer, @leosunmo

@nordmagnus999 is correct, I think:

https://wiki.archlinux.org/index.php/St#Colors suggests that the wrong numbers for cursor, foreground, and background are applied in these lines of the patch.

Observe:

/*
 * Default colors (colorname index)
 * foreground, background, cursor
 */
unsigned int defaultfg = 257;
unsigned int defaultbg = 258;
static unsigned int defaultcs = 256;

[nordmagnus999]

Yeah, didn't know/notice that part for the xresources patch of st, its either this or the other one i mentioned hmm @Interesting-name
I'll try to remove each and see if there a differences, although i think in the long run, it would be better to make/use a patch that replicate default colorscheme of xterm to st, since most terminal like urxvt, etc use xterm (so it would be less confusing to use different terminal/replicate rice imo)

[kgilmer]

The patch theory looks promising. While starting to look into the issue I noticed that my desktop computer seems to work (in that selection in Visual mode is at least visible):

On my laptop which, which has nord-vim installed, I see the issue. But on the desktop with "stock" vim, I do not have the issue. (FYI)

[kgilmer]

@nordmagnus999 , when you say "use xterm" can you explain? Is this something outside of Xresources? Do you have an example?

[nordmagnus999]

Yeah @kgilmer by that i meant, most terminal like urxvt, gnome terminal etc, are based on xterm (and thus use the default xterm colorscheme internally, afaik) so its less confusing trying to replicate/customize them, but terminal like st aren't based on xterm, so yeah.

[nordmagnus999]

oh yeah, i have the same issue you described with the nord-vim plugin btw @kgilmer i do think its a normal issue though (because the colorscheme nord-vim used isn't quite the same one as st use iirc) and since you're probably using both, it overlap and create a mixed colorscheme i think.
It does the same on my end, i even tried using other one beside nord-vim, like solarized-dark, and it overlap.
Beside what we already know (that the patch of st are the cause of the change of colors) afaik, it is normal that this happen with nord-vim.

[kgilmer]

I'm deferring any work on this issue until after the 1.3 release in the interests of shipping it.

[kgilmer]

Regolith 1.4 has moved from st-term being the default to gnome-terminal, and a script from the Nord project is generating a gnome-terminal profile based from Regolith Xresource values. Since this issue is related to st, I will close it. If anyone finds that the same issue exists with gnome-terminal in R1.4, kindly reopen.