256 colour terminal support?

[Roy-Orbison]

Loaded it up and got this:

The same terminal with the Molokai theme that supports 256 color terminals:

[ghost]

You terminal needs to be compatible with the nord theme. This issue does not belong here.

[Roy-Orbison]

@hackedWifi It does belong here. This theme currently limits the palette to 16 colours for any terminal not capable of true colour, rather than detect 256 colour mode (:set t_Co?) and expand the palette accordingly. I'm sure you agree that 256 colours is better than 16, and some closer matches could be used.

[horseinthesky]

Same issue here. I'm using SecureCRT which does not support true color.

For gruvbox and solarized8 themes, there are bash scripts provided which fix colors for 256 color terminals.

[ghost]

this is the reason why I keep telling this issue does not belong on here
Vim in terminal mode must be used with a Nord terminal emulator theme in order to work properly!

Make sure to install one of the currently supported terminal emulator port projects before installing Nord Vim.

Vim in terminal mode uses the 16 color codes provided by the terminal emulator.
When used with another color theme than the one provided by one of Nord's terminal emulator ports, the colors in Vim won't use Nord's color palettes!
This will result in different styles than those defined by Nord Vim and could make it appear that there is a problem with the Nord Vim theme while the actual problem are missing Nord colors.

[Roy-Orbison]

@hackedWifi I don't know why you're getting so worked up about this. Picking some close colours so the theme is legible, out of the box, is not a terrible idea. It is entirely possible to add a note saying the theme will not be 100% accurate unless the terminal's colour scheme is also overridden.

Do you get that not everyone wants to override their entire terminal's default colours for a single program? I've looked at the defaults provided by Nord for PuTTY and the default colours are definitely going to "break" normal output of some other programs. Colours 0 - 5 don't align with defaults, and other colours are duplicated, providing less differentiation:

[husainaloos]

I agree with @Roy-Orbison. Most of us are not going to switch completely to a different terminal emulator (and some might not be able to) because of a theme that supports only true color vs 256-color terminal emulators. It is appropriate to approximate the colors to fit 256-color terminal emulators.

I find myself in the same situation as @Roy-Orbison. I cannot use the theme because terminal.app does not support true color.

And it is perfectly reasonable for the nord-vim devs to reject the proposal of supporting 256-color.

[dagolinuxoid]

I'm going to just throw it out there: https://st.suckless.org/patches/nordtheme/
the simple terminal has true color support.

[Roy-Orbison]

Forked it.

I'm sure I made mistakes so feel free to submit pull requests to correct them.

[Aron-R]

Forked it.

I'm sure I made mistakes so feel free to submit pull requests to correct them.

AAAA thank you I’ve been trying to fix this and this worked for me
I also posted it as an issue before reading this and now I’m like
yep
time to delete that
issue solved

[svengreb]

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.

Therefore it has been added for triage in the central and single-source-of-truth project board that is also described in more detail in the roadmap announcement.

[svengreb]

To add some thoughts of mine about this topic:
The “legacy“ of terminals caused hundreds of questions and “problems“ for users, not only with this theme but colors in terminals in general.
The de-factor standard documentation for terminal colors, especially “true color“, is the termstandard/colors repository. It provides a deeper dive into how colors work the way they do today and also act as a color-compatibility tracker for terminals and applications. The repository is also mentioned as reference in Vim‘s :help xterm-true-color page. I guess everyone should be on the same page regarding colors in terminals after reading through the repository.

Based on that I‘d like to say that I spent hundreds of hours trying to support users to get Nord to work in their terminal and without “true color“ it has always been pain. Then it‘s not Vim itself then the terminal did some weird things rather than just sticking to some semi-specifications and conventions that settled down over the years. It took me so many hours of my life which I could have put to better use.
In my opinion, anything except “true color“ are relics from times that should be left behind. There is no reason to hold on to other schemes like pure 16, 24 or 256 colors while even any UEFI menu is fancier and more colorful than any desktop application 30 years ago.

With that said I think that everyone has recognized what my opinion on the subject is 😄
But I still want to elaborate constructive on this topic, maybe I‘m wrong and someone can simply tell me that it is quite easy to extend the range of supported color spaces.
To keep on topic I‘ll keep my comment on the 256 colors, but some of my next arguments can be applied to others like 16 colors too.
Implementing support for 256 colors is, in contrast to some of the suggested changes in this thread, not as easy as simply adding some more variables with the 256-compatible color IDs:

1. My first, and almost strongest, opinion against 256 colors is that choosing colors that are simply similar to Nord‘s colors is like saying that your recipe tastes the same when you exchange noodles through yogurt!
   Nord‘s colors have been hand-picked with care and they work great because they are exactly those colors and not a single one could be changed without affecting the overall ambience and appearance.
   Choosing “nearby“ colors for a 256-color implementation is not possible because I could then simply leave these tasks to a machine and color themes would then simply be completely useless without the “human touch“.
2. Detecting “true color“ support in a 100% accurate way is impossible!
   To make sue that Nord continues to work fine for everyone who uses a modern terminal, without risking of falling back tp 256 colors due to a false-positive, the color compatibility detection must be waterproof. And this is where it get tricky because there are only specific ways to do so and the results are anything but clear. For example, checking the value of the TERM environment variable, in a terminal that injects it, often yells xterm-256color. This is a nice indicator that we could fall back to 256 colors, but how do we know if “true color“ also works? The answer is the COLORTERM environment variable, but since there is no official specification every terminal can decide whether to set it or not.
   Checking the value of Vim‘s &t_Co variable doesn‘t help either since it also often returns 256 which does not help either. Of course we can check for termguicolors to see if we can use “true color“, but what happens when the user did not set it and the running Vim instance doesn‘t do it either (e.g. due to missing compile flags or pre-defined OS defaults).
   In the end the risk of falling back to 256 colors for users whose setup is capable of providing a great experience with “true colors“ is too high.
3. The complexity will increase drastically for the code due to introduction of various condition checks that are required to decide whether to use “true color“ or a 256-equivalent when styling an element. In addition there are special cases like the increased comment color brightness which might need a 256-nearby-color that is almost identical with nord3 but only differs in brightness. This is not possible with the available colors and therefore causes another loss of visual differentiation.
4. Looking at the available 256 colors the first blocker is the fact that the “Polar Night“ palette can not be replaced by equivalent colors because there simply aren't enough colors in the 256-palette that still reflect the bluish appeal at all. This also applies to the “Frost“ palette which represents the “heart of the theme ambience“ with the main accent colors of Nord. Without these the theme is nothing but a unrelated collection of randomly selected colors from a hardly defined set of 256 colors.

All of these points make it hard, or just impossible, to implement 256-color support without almost creating a whole new theme with its own ambience and appearance.

[Roy-Orbison]

It's just not that big a deal, mate. People who are stuck on 256 colour terminals for whatever reason just wanted Nord. Now they can have something like it or choose another theme.