This poses an issue: a single colorscheme might fit more than one category. It might be coded in Lua, with Tree-sitter support and LSP semantic tokens (see #1466).
In #1753 I decided to classify it as "Tree-sitter supported", but it actually supports LSP semantic tokens. This could confuse users or at the very least misinform them by omission (or misclassification).
There are some ideas that are bouncing in my mind and I want to put them out there.
Tabular view: Having the colorschemes in a table, with link, description, made in Lua, Tree Sitter Support, LSP Semantic Tokens Support as column headers
Pros: Clean and orderly
Cons: Not a list, harder for people to contribute, doesn't translate well into pure text (might wrap to a new line), not very readable without its header
Icons: Adding icons representing each feature, either before or after the description with a legend in the beginning of the section
Pros: Easier to maintain, easier for contributors (copy/paste the icons)
Cons: Not accessible (icons and emojis don't have a customizable description), the section might become an emoji-fest and chaotic.
Tags: Adding text for each feature (Like [TS] for Tree-sitter and [LSP] for LSP Semantic tokens) at the beginning or end of the description
Pros: Accessible, easy to contribute and maintain, searchable
Cons: The section may become chaotic with all the tags, possibly drowning the descriptions.
I don't think we need to touch the "Colorscheme creation" and "Colorscheme switchers" subsections, since they're something completely different from "just colorschemes".
I would like to know your opinions on the matter.
Originally created by @Penaz91 on GitHub (Oct 24, 2025).
Original GitHub issue: https://github.com/rockerBOO/awesome-neovim/issues/1755
Originally assigned to: @rockerBOO, @Penaz91, @DrKJeff16 on GitHub.
I've been checking to clean up some issues and while preparing some pull requests, I've come across issues #946 and #1466 .
This made me realize that we might be veering towards having issues with colorscheme classification.
As of now, we have 4 sections:
- Tree-sitter supported colorschemes
- Lua colorscheme
- Colorscheme creation
- Colorscheme switchers
With a 5th option coming from #946:
- Colorschemes with LSP semantic tokens support
--------
This poses an issue: a single colorscheme might fit more than one category. It might be coded in Lua, with Tree-sitter support and LSP semantic tokens (see #1466).
In #1753 I decided to classify it as "Tree-sitter supported", but it actually supports LSP semantic tokens. This could confuse users or at the very least misinform them by omission (or misclassification).
---------
There are some ideas that are bouncing in my mind and I want to put them out there.
- **Tabular view:** Having the colorschemes in a table, with link, description, made in Lua, Tree Sitter Support, LSP Semantic Tokens Support as column headers
- **Pros:** Clean and orderly
- **Cons:** Not a list, harder for people to contribute, doesn't translate well into pure text (might wrap to a new line), not very readable without its header
- **Icons:** Adding icons representing each feature, either before or after the description with a legend in the beginning of the section
- **Pros:** Easier to maintain, easier for contributors (copy/paste the icons)
- **Cons:** Not accessible (icons and emojis don't have a customizable description), the section might become an emoji-fest and chaotic.
- **Tags:** Adding text for each feature (Like `[TS]` for Tree-sitter and `[LSP]` for LSP Semantic tokens) at the beginning or end of the description
- **Pros:** Accessible, easy to contribute and maintain, searchable
- **Cons:** The section may become chaotic with all the tags, possibly drowning the descriptions.
--------
I don't think we need to touch the "Colorscheme creation" and "Colorscheme switchers" subsections, since they're something completely different from "just colorschemes".
I would like to know your opinions on the matter.
This would take quite some time for our part since it'd mean checking a huge chunk of the current colorschemes (which are very numerous). Nevertheless I do agree the sub-sections are an issue for the reader.
Now, about how to deal with this... remember awesome-list and awesome-lint. Tabular View, and I suspect Icon View, are likely not a choice.
I don't think we need to touch the "Colorscheme creation" and "Colorscheme switchers" subsections, since they're something completely different from "just colorschemes".
100% agreed.
<!-- gh-comment-id:3444773870 -->
@DrKJeff16 commented on GitHub (Oct 24, 2025):
This would take quite some time for our part since it'd mean checking a huge chunk of the current colorschemes (which are very numerous). Nevertheless I do agree the sub-sections are an issue for the reader.
Now, about how to deal with this... remember `awesome-list` and `awesome-lint`. Tabular View, and I suspect Icon View, are likely not a choice.
---
> I don't think we need to touch the "Colorscheme creation" and "Colorscheme switchers" subsections, since they're something completely different from "just colorschemes".
100% agreed.
@Penaz91 In my opinion we could make other distinctions in the long term. However, filtering through colorschemes support by what do they support is a potentially tricky thing (e.g. "Does X colorscheme support Y plugin?", "Does X plugin has both light and dark variants?").
Maybe I'm just over-analyzing it. After all it's hard for me not to nitpick with intent of constructive analysis (I hope).
<!-- gh-comment-id:3452475233 -->
@DrKJeff16 commented on GitHub (Oct 27, 2025):
@Penaz91 In my opinion we could make other distinctions in the long term. However, filtering through colorschemes support by what do they support is a potentially tricky thing (e.g. _"Does X colorscheme support Y plugin?"_, _"Does X plugin has both light and dark variants?"_).
Maybe I'm just over-analyzing it. After all it's hard for me not to nitpick with intent of constructive analysis (I hope).
This could become something akin to "Plugin support"
Does X plugin has both light and dark variants?
Either we think about "Has Variants" as kind of tag, or we can just ignore it completely. We need to understand what is important for the end user and what isn't.
Such definition may change from person to person, but definitely Tree-sitter is one such important feature. Another one could be LSP Semantic Tokens. By the same thought some may think that "Lua colorscheme" is not a useful distinction.
What I think is that we need to strike a balance between informing the user and not overload them with information they might not care about.
<!-- gh-comment-id:3452659349 -->
@Penaz91 commented on GitHub (Oct 27, 2025):
Obviously we would need to put a limit to that.
> Does X colorscheme support Y plugin?
This could become something akin to "Plugin support"
> Does X plugin has both light and dark variants?
Either we think about "Has Variants" as kind of tag, or we can just ignore it completely. We need to understand what is important for the end user and what isn't.
Such definition may change from person to person, but definitely Tree-sitter is one such important feature. Another one could be LSP Semantic Tokens. By the same thought some may think that "Lua colorscheme" is not a useful distinction.
What I think is that we need to strike a balance between informing the user and not overload them with information they might not care about.
@VladimirMarkelov commented on GitHub (Oct 27, 2025):
Either we think about "Has Variants" as kind of tag, or we can just ignore it completely
I'd prefer having a tag "Has Variants". A bit of my experience: I used dark themes for a long time and was happy as almost every colorscheme had a dark version. But when I switched to light themes, it became a little frustrating. Because a lot of themes do not have a light version and their descriptions do not tell about it(the opposite case, when a theme has a light version but it does not mention it in its description, also happens). So, I have to open a theme's home page to check if it is dark-only one or there are more choices. It can be time-consuming.
<!-- gh-comment-id:3452775759 -->
@VladimirMarkelov commented on GitHub (Oct 27, 2025):
> Either we think about "Has Variants" as kind of tag, or we can just ignore it completely
I'd prefer having a tag "Has Variants". A bit of my experience: I used dark themes for a long time and was happy as almost every colorscheme had a dark version. But when I switched to light themes, it became a little frustrating. Because a lot of themes do not have a light version and their descriptions do not tell about it(the opposite case, when a theme has a light version but it does not mention it in its description, also happens). So, I have to open a theme's home page to check if it is dark-only one or there are more choices. It can be time-consuming.
[Plugins] for "has plugin support" (without specifying which ones or we'll have a billion tags)
[Lua] for "Written in Lua", although I don't really know if that's of interest for the end user. Usually it's the combination of colors and its features that make the difference, right?
I wouldn't add a ton of "usable" tags, mostly for fear that they would drown the descriptions.
<!-- gh-comment-id:3453068475 -->
@Penaz91 commented on GitHub (Oct 27, 2025):
So what we have so far:
- `[TS]` for Tree-sitter support
- `[LSP]` for LSP Semantic Tokens Support
- `[L/D]` for "has light and dark variants"
Other ideas may include
- `[Plugins]` for "has plugin support" (without specifying which ones or we'll have a billion tags)
- `[Lua]` for "Written in Lua", although I don't really know if that's of interest for the end user. Usually it's the combination of colors and its features that make the difference, right?
I wouldn't add a ton of "usable" tags, mostly for fear that they would drown the descriptions.
Throwing an example here of how the first 5 plugins would probably look:
kuri-sun/yoda.nvim - [TS][LSP][L/D][Plug][Lua] Muted green palette for focused, balanced editing.
wurli/cobalt.nvim - [TS][Plug][Lua] A (mostly) faithful port of the classic blue theme from TextMate.
datsfilipe/min-theme.nvim - [TS][LSP][Plug][Lua] It's a port of Min, a minimal theme for VSCode, written in Lua.
github-main-user/lytmode.nvim - [TS][LSP][Plug][Lua]A unique in-between theme inspired by LYT-Mode for Obsidian. Not quite dark, not quite light — just right.
datsfilipe/vesper.nvim - [TS][LSP][Plug][Lua] It's a port of the popular VS Code theme Vesper, written in Lua.
Technically speaking, we could also exploit GitHub's <kbd></kbd> tags to more tag-like look:
kuri-sun/yoda.nvim - TSLSPL/DPlugLua Muted green palette for focused, balanced editing.
<!-- gh-comment-id:3474820052 -->
@Penaz91 commented on GitHub (Oct 31, 2025):
Throwing an example here of how the first 5 plugins would probably look:
- [kuri-sun/yoda.nvim](https://github.com/kuri-sun/yoda.nvim) - `[TS][LSP][L/D][Plug][Lua]` Muted green palette for focused, balanced editing.
- [wurli/cobalt.nvim](https://github.com/wurli/cobalt.nvim) - `[TS][Plug][Lua]` A (mostly) faithful port of the classic blue theme from TextMate.
- [datsfilipe/min-theme.nvim](https://github.com/datsfilipe/min-theme.nvim) - `[TS][LSP][Plug][Lua]` It's a port of Min, a minimal theme for VSCode, written in Lua.
- [github-main-user/lytmode.nvim](https://github.com/github-main-user/lytmode.nvim) - `[TS][LSP][Plug][Lua]`A unique in-between theme inspired by LYT-Mode for Obsidian. Not quite dark, not quite light — just right.
- [datsfilipe/vesper.nvim](https://github.com/datsfilipe/vesper.nvim) - `[TS][LSP][Plug][Lua]` It's a port of the popular VS Code theme Vesper, written in Lua.
Technically speaking, we could also exploit GitHub's `<kbd></kbd>` tags to more tag-like look:
- [kuri-sun/yoda.nvim](https://github.com/kuri-sun/yoda.nvim) - <kbd>TS</kbd><kbd>LSP</kbd><kbd>L/D</kbd><kbd>Plug</kbd><kbd>Lua</kbd> Muted green palette for focused, balanced editing.
On a first glance I'd stick with the former proposal.
That being said, the latter looks fancier, for sure.
<!-- gh-comment-id:3475243358 -->
@DrKJeff16 commented on GitHub (Oct 31, 2025):
On a first glance I'd stick with the former proposal.
That being said, the latter looks fancier, for sure.
@Penaz91 @rockerBOO I'm currently working on this. However the more I think about the following the more I need to ask:
Should a plugin with lualine.nvim support count as [Plug]?
Maaany themes have lualine support but no other plugins, so I'm worried it might be misleading in the long run if we include a [Plug] for plugins just for having lualine.nvim support.
<!-- gh-comment-id:3662631310 -->
@DrKJeff16 commented on GitHub (Dec 16, 2025):
@Penaz91 @rockerBOO I'm currently working on this. However the more I think about the following the more I need to ask:
Should a plugin with `lualine.nvim` support count as `[Plug]`?
Maaany themes have lualine support but no other plugins, so I'm worried it might be misleading in the long run if we include a `[Plug]` for plugins just for having lualine.nvim support.
Should a plugin with lualine.nvim support count as [Plug]?
Maaany themes have lualine support but no other plugins, so I'm worried it might be misleading in the long run if we include a [Plug] for plugins just for having lualine.nvim support.
I see what you mean, such plugins "technically have plugin support", but it's just one. At this point we can either:
Drop the [Plug] tag because it loses meaning: Plug != LuaLine
Go with the "technical definition" and if the colorscheme supports "at least one" plugin, then it gets the tag.
I think such tag is secondary anyway so I'm a bit partial to the first solution, mostly cause it's cleaner.
<!-- gh-comment-id:3664072867 -->
@Penaz91 commented on GitHub (Dec 17, 2025):
> Should a plugin with `lualine.nvim` support count as `[Plug]`?
>
> Maaany themes have lualine support but no other plugins, so I'm worried it might be misleading in the long run if we include a `[Plug]` for plugins just for having lualine.nvim support.
I see what you mean, such plugins "technically have plugin support", but it's just one. At this point we can either:
- Drop the `[Plug]` tag because it loses meaning: `Plug != LuaLine`
- Go with the "technical definition" and if the colorscheme supports "at least one" plugin, then it gets the tag.
I think such tag is secondary anyway so I'm a bit partial to the first solution, mostly cause it's cleaner.
I think it is safe to remove the [Plug] tag. If it is required in the future for some reason (which I am inclined to doubt) I can take care of it.
<!-- gh-comment-id:3664150689 -->
@DrKJeff16 commented on GitHub (Dec 17, 2025):
I think it is safe to remove the `[Plug]` tag. If it is required in the future for some reason (which I am inclined to doubt) I can take care of it.
@rockerBOO @Penaz91 I've linked the PR that addresse this (#2029). You can make changes in the fix/colorschemes branch if you so desire.
<!-- gh-comment-id:3664164884 -->
@DrKJeff16 commented on GitHub (Dec 17, 2025):
@rockerBOO @Penaz91 I've linked the PR that addresse this (#2029). You can make changes in [the `fix/colorschemes` branch](https://github.com/rockerBOO/awesome-neovim/tree/fix/colorschemes) if you so desire.
Thanks for your work, workday has begun here so it'll have to wait a few hours. But I'll definitely check on it.
<!-- gh-comment-id:3664360783 -->
@Penaz91 commented on GitHub (Dec 17, 2025):
Thanks for your work, workday has begun here so it'll have to wait a few hours. But I'll definitely check on it.
FOR COLLABORATORS: There must be highlight groups resembling: @lsp.xxxxx.xxxx.
[L/D] - Has both "light" and "dark" variants.
[Lua] - Is written in Lua.
[Fnl] - Is written in Fennel.
<!-- gh-comment-id:3667722156 -->
@DrKJeff16 commented on GitHub (Dec 18, 2025):
I've followed these guidelines:
- `[TS]` - Has Tree-sitter highlighting.
- `[LSP]` - Has LSP Semantic Tokens support.
- **_FOR COLLABORATORS_: There must be highlight groups resembling: `@lsp.xxxxx.xxxx`.**
- `[L/D]` - Has both "light" and "dark" variants.
- `[Lua]` - Is written in Lua.
- `[Fnl]` - Is written in Fennel.
Great job, I'll check the full PR later, but what I saw yesterday was good already.
<!-- gh-comment-id:3668783213 -->
@Penaz91 commented on GitHub (Dec 18, 2025):
Great job, I'll check the full PR later, but what I saw yesterday was good already.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Penaz91 on GitHub (Oct 24, 2025).
Original GitHub issue: https://github.com/rockerBOO/awesome-neovim/issues/1755
Originally assigned to: @rockerBOO, @Penaz91, @DrKJeff16 on GitHub.
I've been checking to clean up some issues and while preparing some pull requests, I've come across issues #946 and #1466 .
This made me realize that we might be veering towards having issues with colorscheme classification.
As of now, we have 4 sections:
With a 5th option coming from #946:
This poses an issue: a single colorscheme might fit more than one category. It might be coded in Lua, with Tree-sitter support and LSP semantic tokens (see #1466).
In #1753 I decided to classify it as "Tree-sitter supported", but it actually supports LSP semantic tokens. This could confuse users or at the very least misinform them by omission (or misclassification).
There are some ideas that are bouncing in my mind and I want to put them out there.
[TS]for Tree-sitter and[LSP]for LSP Semantic tokens) at the beginning or end of the descriptionI don't think we need to touch the "Colorscheme creation" and "Colorscheme switchers" subsections, since they're something completely different from "just colorschemes".
I would like to know your opinions on the matter.
@DrKJeff16 commented on GitHub (Oct 24, 2025):
This would take quite some time for our part since it'd mean checking a huge chunk of the current colorschemes (which are very numerous). Nevertheless I do agree the sub-sections are an issue for the reader.
Now, about how to deal with this... remember
awesome-listandawesome-lint. Tabular View, and I suspect Icon View, are likely not a choice.100% agreed.
@DrKJeff16 commented on GitHub (Oct 27, 2025):
@Penaz91 In my opinion we could make other distinctions in the long term. However, filtering through colorschemes support by what do they support is a potentially tricky thing (e.g. "Does X colorscheme support Y plugin?", "Does X plugin has both light and dark variants?").
Maybe I'm just over-analyzing it. After all it's hard for me not to nitpick with intent of constructive analysis (I hope).
@Penaz91 commented on GitHub (Oct 27, 2025):
Obviously we would need to put a limit to that.
This could become something akin to "Plugin support"
Either we think about "Has Variants" as kind of tag, or we can just ignore it completely. We need to understand what is important for the end user and what isn't.
Such definition may change from person to person, but definitely Tree-sitter is one such important feature. Another one could be LSP Semantic Tokens. By the same thought some may think that "Lua colorscheme" is not a useful distinction.
What I think is that we need to strike a balance between informing the user and not overload them with information they might not care about.
@DrKJeff16 commented on GitHub (Oct 27, 2025):
@Penaz91 You've convinced me. Mmmmhhhh... I'd say tags are the better alternative.
@VladimirMarkelov commented on GitHub (Oct 27, 2025):
I'd prefer having a tag "Has Variants". A bit of my experience: I used dark themes for a long time and was happy as almost every colorscheme had a dark version. But when I switched to light themes, it became a little frustrating. Because a lot of themes do not have a light version and their descriptions do not tell about it(the opposite case, when a theme has a light version but it does not mention it in its description, also happens). So, I have to open a theme's home page to check if it is dark-only one or there are more choices. It can be time-consuming.
@Penaz91 commented on GitHub (Oct 27, 2025):
So what we have so far:
[TS]for Tree-sitter support[LSP]for LSP Semantic Tokens Support[L/D]for "has light and dark variants"Other ideas may include
[Plugins]for "has plugin support" (without specifying which ones or we'll have a billion tags)[Lua]for "Written in Lua", although I don't really know if that's of interest for the end user. Usually it's the combination of colors and its features that make the difference, right?I wouldn't add a ton of "usable" tags, mostly for fear that they would drown the descriptions.
@Penaz91 commented on GitHub (Oct 31, 2025):
Throwing an example here of how the first 5 plugins would probably look:
[TS][LSP][L/D][Plug][Lua]Muted green palette for focused, balanced editing.[TS][Plug][Lua]A (mostly) faithful port of the classic blue theme from TextMate.[TS][LSP][Plug][Lua]It's a port of Min, a minimal theme for VSCode, written in Lua.[TS][LSP][Plug][Lua]A unique in-between theme inspired by LYT-Mode for Obsidian. Not quite dark, not quite light — just right.[TS][LSP][Plug][Lua]It's a port of the popular VS Code theme Vesper, written in Lua.Technically speaking, we could also exploit GitHub's
<kbd></kbd>tags to more tag-like look:@DrKJeff16 commented on GitHub (Oct 31, 2025):
On a first glance I'd stick with the former proposal.
That being said, the latter looks fancier, for sure.
@DrKJeff16 commented on GitHub (Dec 16, 2025):
@Penaz91 @rockerBOO I'm currently working on this. However the more I think about the following the more I need to ask:
Should a plugin with
lualine.nvimsupport count as[Plug]?Maaany themes have lualine support but no other plugins, so I'm worried it might be misleading in the long run if we include a
[Plug]for plugins just for having lualine.nvim support.@Penaz91 commented on GitHub (Dec 17, 2025):
I see what you mean, such plugins "technically have plugin support", but it's just one. At this point we can either:
[Plug]tag because it loses meaning:Plug != LuaLineI think such tag is secondary anyway so I'm a bit partial to the first solution, mostly cause it's cleaner.
@DrKJeff16 commented on GitHub (Dec 17, 2025):
I think it is safe to remove the
[Plug]tag. If it is required in the future for some reason (which I am inclined to doubt) I can take care of it.@DrKJeff16 commented on GitHub (Dec 17, 2025):
@rockerBOO @Penaz91 I've linked the PR that addresse this (#2029). You can make changes in the
fix/colorschemesbranch if you so desire.@Penaz91 commented on GitHub (Dec 17, 2025):
Thanks for your work, workday has begun here so it'll have to wait a few hours. But I'll definitely check on it.
@DrKJeff16 commented on GitHub (Dec 18, 2025):
I've followed these guidelines:
[TS]- Has Tree-sitter highlighting.[LSP]- Has LSP Semantic Tokens support.@lsp.xxxxx.xxxx.[L/D]- Has both "light" and "dark" variants.[Lua]- Is written in Lua.[Fnl]- Is written in Fennel.@Penaz91 commented on GitHub (Dec 18, 2025):
Great job, I'll check the full PR later, but what I saw yesterday was good already.
@DrKJeff16 commented on GitHub (Dec 18, 2025):
The bulk of the job has been done!