bug: color differentiation between string & non-string primitives

[chrisgrieser]

Did you check docs and existing issues?

• I have read all the tokyonight.nvim docs
• I have updated the plugin to the latest version before submitting this issue
• I have searched the existing issues of tokyonight.nvim
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

nvim v0.11.5

Operating system/version

macOS 26.2 (arm)

Describe the bug

In toykonight, string values have a different color than numbers/booleans, making them easily distinguishable. In comparison, teide gives them all the same color.

Steps To Reproduce

Expected Behavior

Repro

[serhez]

Hey! This is not a bug, but a feature 😁 Semantically, all of those are values to me, just different types (strings or character arrays, booleans, and numbers). I do not plan on changing this. I was even considering making constant variables the same color, but eventually opted for a special color for them that was in between the ones for variables (white) and values (green), resulting in a dimmed green.

[serhez]

And just to justify my choice a bit more: the issue with giving a distinct color to every value type is that, at some point, you run out of colors. And, even if you didn't, there are not so many colors already for distinguishing other --more important, I would say-- stuff like functions vs. variables vs. values vs. classes vs. directives vs. operators vs. flow-altering keywords (e.g., if-else, for-loops, etc.), ... TokyoNight (and most other themes) seem to make the arbitrary distinction between strings and other value types; perhaps it's justified in some way, but as of now I do not find a convincing distinction myself. The other thing I thought hard about was if None/nil/NULL (depending on language) deserved a special color as a special no-type value. As of now, it shares color with the rest of values (green), but I may give it a twist in the future because I do see a justification in that one, where distinguishing them from a quick-glance can be useful (which I want to be part of the Teide philosophy, not just the theme being visually pleasing).

[chrisgrieser]

I mean, I see why you could have such a stance, but I personally prefer the color differentiation, since it lets me spot a 1 that should have been a "1" more quickly.

I don't see a problem overwriting the highlight myself, but as a suggestion, I think it might make sense to just add a setting for it in the colorscheme settings for less experienced users, since it's a somewhat opinionated decision.

[serhez]

I like the number vs string-of-a-number point... I'll think about it :)

To be realistic though, there are hardly any colors left in the palette, besides shades of already-used colors. If I make values blue, then it clashes with function-related words; if I make them orange, then it clashes with class/object-related stuff, yellow for types, red for definition & program-altering keywords, etc... The semantical differences between these kinds of words are way greater than for values of different types and, while your use-case seems useful, I think the other ones are more so. Maybe this discussion sounds silly to some, but I really want to not compromise on coherence.

I can try finding a different green for them? I'll re-open the issue and think about it. If I get some good ideas, I'll come back here.

[diego898]

I mean, I see why you could have such a stance, but I personally prefer the color differentiation, since it lets me spot a 1 that should have been a "1" more quickly.

I don't see a problem overwriting the highlight myself, but as a suggestion, I think it might make sense to just add a setting for it in the colorscheme settings for less experienced users, since it's a somewhat opinionated decision.

Im pretty novice to color schemes, highlight groups, etc. would you mind sending your overwrites here as well? Id also like the behavior you describe

But totally respect the theme authors preference+decision!

[chrisgrieser]

@diego898 Haven't done it myself yet, but it's something like using :Inspect to identify the highlight group and then using vim.cmd.highlight to add a link to another highlight group in your config.

Though it's probably easier to wait a bit since serhez is maybe just gonna add a setting for it.

[serhez]

Small update here: I've been experimenting with multiple colors over the last weeks, but so far I haven't found anything that I like enough to update the main branch. Here is an example of what I've been trying: