[Collaborators] The Colorscheme Conundrum

[Penaz91]

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.

[DrKJeff16]

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.

[DrKJeff16]

@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]

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.

[DrKJeff16]

@Penaz91 You've convinced me. Mmmmhhhh... I'd say tags are the better alternative.

[VladimirMarkelov]

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.

[Penaz91]

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]

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.