Visual in cterm missing reverse

[raggi]

hi Visual appears to be missing a color setting for cterm, resulting in visual selection and block selection being invisible.

I set hi Visual cterm=reverse in order for it to be usable.

[arcticicestudio]

Hi @raggi 👋, thanks for your contribution 👍🏼

I've tried to reproduce the problem, but this is some of these typical “works on my machine“ situations:

gh-243-reproduction.mp4

When setting the cterm attribute to reverse all elements matched by the currently active syntax parser will get their own color which makes the the selection looks kind of “blocky and clunky“:

gh-243-hi_visual_reverse.mp4

If this is what you'd like to have selection look like you can simply use it by overriding the highlighting group only when Nord is set as active colorscheme.

Anyway, in order to ensure the problem is related to the Nord theme you need to reproduce it with a minimal and clean configuration. This can be done by creating new configuration file with any name (e.g. testrc) and run Vim with the following command: vim -u testrc
For me as a theme author it is not possible to know if the theme is the root cause of the problem when there are other attributes set in the configuration because each one might break the theme.

Here's an minimal test configuration you can use to try to reproduce the problem (supposed you're using vim-plug):

call plug#begin(expand('~/.vim/plugged'))
Plug 'arcticicestudio/nord-vim'
call plug#end()

set nocompatible
if (has("termguicolors"))
  set termguicolors
endif

syntax enable
colorscheme nord

As you can see in the example configuration I've added the termguicolors settings which could be one reason why the color is not rendered correctly. This is because the *_term attributes make use of the colors that are provided by the terminal color scheme which might be for example iTerm2 or Alacritty. The *_gui variables on the other side are used when Vim runs in GUI mode. So in order to run Vim in a terminal but use colors like in GUI mode the termguicolors variable must be set and your terminal emulator must support “true colors“ (24bit).
This might also be the reason why your selection is invisible.

Unfortunately terminal colors are quite complex due to their long history, but modern terminal emulators should be all capable of rendering "True Colors". You should make sure to check out the great “Terminal Colors“ gist that provides many details about color rendering in terminal emulators, tracking of supported terminal emulator projects and answers to common confusions about terminal colors. The “Colours in terminal“ gist is also quite helpful to learn more about the actual rendering engines and standards used by these terminal emulators.
There are also a lot of blog posts like this and this one that help to handle different use case with various terminal emulators in combination with different CLI and TUI applications.

Could you please try to either use the example configuration or set the termguicolors setting in your current configuration and check whether colors are then displayed correctly?

[raggi]

Thank you for the prompt and detailed response.

I think the issue I experienced was rooted in termguicolors not being set, which is as you say, somewhat of a mess derived from TTY history, as we have yet to see a standard for termcap to advertise 24bit color support, which means termguicolors can not be derived from the environment. I was able to demonstrate, after installing termcaps for both my terminal emulator, and tmux by hand (thanks macOS), that setting termguicolors then works for me. I had to install the termcaps otherwise other side effects came about, which is very sad.

So I think the bug I want to report is therefore different, which is that the 256 color fallback is not usable, specifically, in my original case, without termguicolors set, the highlight in visual mode was completely invisible. What I'd like is a fallback that is in some way visible instead, as this way I can sync profiles using this colorscheme to remote machines that may or may not have sufficient preconfiguration as to support 24bit well over remote connections such as ssh. As I write this, I do now see in the readme it says Build for Vim's terminal- and GUI mode with true colors, though this didn't stand out for me maybe as much as it should have when I first tried the software.

I'd love to have a more usable fall-back for 256 color, but it's also fine by me if you are constraining the project to 24bit only.

[svengreb]

@raggi Thank you for your patience! 🙏🏼
It‘s been a while since I had free time to focus more on Nord, and my open source projects in general, and invest time in this issue due to work-life balance.

I recently published the first “Northern Post — The state and roadmap of Nord“ announcement which includes all details about the plans and future of the Nord project, including the goal of catching up with the backlog. This issue is part of the backlog and therefore I want to triage and process it to get one step closer to a “clean state“. Read the announcement about reaching the “clean“ contribution triage state in Nord‘s discussions for more details about the goal.

Due to the scope of this issue of not being “purely technical“, or being related to the project‘s code at all, I‘ll convert it into a discussion for Nord‘s central community hub on GitHub. This way the repository is easier to maintain by separating conversations about the actual code while also making help requests, ideas and other contributions from users more visible and supportable by the community.

---

@raggi Would be nice if you could quickly check if this discussion can be closed since this is not related to this theme‘s code.
I also recently described the problems and implications with 256-color support in #162 and how this is not the design goal of Nord. There are some community ports/forks of the Nord Vim that are explicitly created for this if you‘d like to use it anyway, but note that this is not “officially“ supported and might be out-of-date with the upstream project.