Coming up with a policy for "built in" themes

[the-mikedavis]

We don't currently have a formal policy for when we accept themes. Historically we've accepted basically all theme PRs regardless of popularity or how they look. There are now 134 themes in runtime/themes/*.toml at time of writing and it's getting pretty crowded. On the upside it means a lot of options to choose from when getting started with Helix. (Sometimes I try out the built in light themes when I'm working under the sun :). Having a lot of themes is a lot of maintenance burden though. It means that sweeping changes to themes are hard to land. We generally don't require PRs that add a new theme key to add values for it for the existing themes, so when a feature lands that adds a key, there's usually a scramble to update many themes. Even when these keys have fallbacks, it's cumbersome to test the fallback behavior for each theme. Theme maintenance is also a non-trivial amount of review work. It's very straightforward review but over the course of a release we end up coordinating with many theme authors and clicking a lot of buttons total in order to get it done - see the theme change parts of the CHANGELOG for reference.

I wanted to open this discussion up to explore some ideas to change how we accept themes. Naively accepting all themes has always been a temporary policy in my mind but I don't have concrete plans for what we should do instead.

[the-mikedavis]

My personal preference would be to limit the themes we have in the repo to the default one, a few of the base16 themes and some number of popular themes. We could have a follow-up discussion to figure out which themes we would keep, but basically we would limit ourselves to a constant number of (say, 10) "big name" themes, for example catppuccin and tokyonight. Other themes would be maintained in personal or upstream repositories (some themes have repos with color schemes for a bunch of different programs for example). We would try to maintain these limited in-repo themes more rigorously.

This would hurt theme discovery, but I think that goal is better accomplished by (community) projects, for example https://vimcolorschemes.com/ from the Vi world.

[markstos]

I would also start with a very small number of built-in themes, because what's popular today will be different tomorrow. (I remember when tokyonight) didn't exist. Going forward, the project is likely to add new, popular themes as defaults while wanting to remaining somewhat backward compatible, so some older themes might stay.

Keeping a constant number, like 10, also seems fair too. Even when an older theme gets bumped out of the Core 10 later, the worst that would happen during an upgrade is that the theme changes and some users have to check the changelog to find out where they get the retired theme.

As a user, I would rather have the core devs working on core features, not theme management. I don't mind if there's extra step to install my favorite theme, especially once the future plugin system makes that easy.

[tryoxiss]

Id go a step further and say that ONLY the default and base16 themes should be in the core repo, as @markstos pointed out what is popular changes, and it would be best to avoid breaking changes.

As some other comments are saying, a seperate theme repo that can be optionally sourced would be a good compromise, keep the core themes extremely minimal but allow easy sourcing of more themes. (Perhaps a editor.theme-sources option, and it could look for valid theme files with the .toml extension or something)

[the-mikedavis]

An option I think is interesting is to create a separate repo for themes, either under this organization or a separate GitHub organization. Optionally we could source the themes from this repo on release, so we still end up with a large number of "built in" themes. A community theme repo could hand out write access much more freely than we do for the main codebase here, and there could be a system of maintainer(s) per theme like there is for languages in nvim-treesitter for example. This option would require a lot of community work - I'm not really interested in leading this effort myself.

[markstos]

The success of this would depend on whether there are people who want to dedicate time to theme maintenance. However that is would be spending a fair amount of time maintaining themes they don't use. I know some projects have this, but decentralized themes might be more sustainable in the long run. What seems more sustainable to maintain in a central place is a simple wiki page that links to all the decentralized themes from one place.

[pascalkuthe]

Maybe just to add to this: i think one of the reasons we had themes in the repo to begin with was that so we could handle breaking changes more easily and update themes.

This hasn't really been effective for a while. We don't do too many breaking themeing changes. The main changes that require themeing updates are adding new features. But requiring a developer to update 134 themes as a requirement for a change to master is completely impractical (just the conflicts and rebasing aline would be a nightmare). In practice adding any new feature results in a flourish of "update theme XY" PRs and issues (and many themes also don't get updated). So while this is a nice idea in theory I think it only works if you have a very small set of "core" themes where mandating an update to themes for a PR (or a maintainer doing it in a followup) is actually practical.

I also feel that moving themes out of the repo would result in improved maintainance for themes. We just dont have the bandwidth to triage/test/review all issue and changes related to themes (or keep track of issues). In practice we just merge changes if there isn't anything obiously wrong. Theming issues also just get lost in our fairly large issue tracker. So a more focused repo would help with that.

So definitly in favor of moving themes out sooner rather than later.

[David-Else]

I suggest that in the next Helix release notes you ask people to click on a GitHub discussions poll to say which theme they use, then you can get some real data as to which themes are being used the most and which are not. It might be a bit of a chore to create the poll by hand with so many themes, but I am sure AI could automate some of it.

[Rudxain]

I agree. But a simple bot would be enough. AI may confuse "Darcula" with "Dracula".

I suggest that instead of listing all theme files, we should group them. For example, all of the monokai* themes could be shown as simply "Monokai"

[James-Firth]

I'm sure anyone, myself included, will be slightly inconvenienced if our favourite themes don't make the cut.
(edit: To be clear I mean that as: don't worry too much about picking the "right" ones to keep 😄 )

I did really like that my favourite (Dracula) was already easily accessible via the :theme list.

I do like the idea of having an official separate repo with themes.

My suggestion is there should be a new feature to pull/install some (or all?) themes from that official repo via something like :theme install [NAME | "all"]. However I could see that not fitting in the idea of having the editor not too bloated with features.

[ascarter]

Maybe the config for the theme could be a GitHub URL and helix could download the theme file to the local config directory. That way users could just have a GitHub URL for the theme in their config and have it appear locally without having to do it yourself. I know - this belongs in an extension...

[getreu]

Theme maintenance is also a non-trivial amount of review work. It's very straightforward review but over the course of a release we end up coordinating with many theme authors and clicking a lot of buttons total in order to get it done - see the theme change parts of the CHANGELOG for reference.

Why not delegating this task to a volunteer? It could be someone without (Rust) programming experience.

I like that Helix comes with many built-in themes. Even knowing, that not all are perfect. The config file allows me to fine tune them easily to my personal preferences. And, I do not use all of the features anyway!

Suggestion

I suggest that instead of listing all theme files, we should group them. For example, all of the monokai* themes could be shown as simply "Monokai"

We could classify the themes in tier groups, like Rust targets, e.g.

• Tier 1: is feature complete and tested,
• Tier 2: some new features are not yet implemented
• Tier 3: not tested and actively maintained, use at own risk
• ...

This way we continue shipping all themes and ease the burden of maintaining them all with the same care.

Helix is a pragmatic editor: it should behave as you'd expect out of the box

So far, Helix comes with (almost) all I need out of the box. I am afraid that with the planned theme selection my favorite ones will be ruled out.

[markstos]

Why not delegating this task to a volunteer?

I don't speak as a Helix project rep, but as someone who helps maintain a number of popular open source projects. Volunteers don't always appear and even when they do, they still need to be managed. And they also quit, and then a new volunteer needs to be found, but none may appear, and in the meantime maintenance still needs to be done. So while, yes, this could be done the project core with a volunteer, having the themes outside of the core relieves the core team of not only the theme maintenance, but also management of a theme maintenance volunteer.

So far, Helix comes with (almost) all I need out of the box. I am afraid that with the planned theme selection my favorite ones will be ruled out.

You may need to google "helix editor [favorite theme name]", or maybe someone will volunteer to link to all the known themes. It should not be much extra effort to install your theme, and you do it once.

[markstos]

The way VS Code handles this is described like this in their docs:

"There are several out-of-the-box color themes in VS Code for you to try. Many more themes have been uploaded to the VS Code Extension Marketplace by the community."

I think that strikes a good balance. Provide 10 or so out of the box, and make it easy to find many, many more maintained by the community, discoverable from a central location.

[johnc219]

Trying to think what the path could look like.

core themes: maintained in main repo
non-core/retired themes: not maintained in main repo

Goals

• continue providing simple way for theme authors to create/share helix themes
• make progress orthogonal to plugin system
• reduce maintenance burden
• enable high quality bar for core themes

from a user perspective

• provide enough advance notice for users of retired themes
• communicate upcoming breaking changes.
• provide guidance on how to prepare/transition
• make it simple to learn how to add a non-core them to your config

Example Steps

1. Freeze current non-core themes. Only bug fixes to non-core themes accepted. New non-core themes not accepted.
2. To minimize surprise, reference/pin new theme policy wherever people usually go when they start working on a theme (e.g. theming docs, issues)
3. Merge/close existing PRs relating to non-core themes
4. At this point, non-core themes are frozen
5. Copy or move non-core themes to a separate repo. Make it a dependency of the main repo
   • Maybe too aggressive, but the repo could be archived/read-only, or more generally "supported until date X / next major release". The expectation would be that this is a hold-over repo rather than the new spot to add new themes. I think that would encourage theme developers/maintainers to own helix themes.
   • Alternatively, the repo is community maintained, not a dependency of the main repo, and installation could involve cloning the repo into your .config/helix/themes/ dir. Would such a repo benefit from being in the helix organization? Maybe, but I don't think it's necessary: (a) I think that repo could organically sprout. (b) A repo in the main organization has a greater expectation of continued maintenance / having a high bar, leading back to the maintenance burden issue.
6. After enough grace period, drop non-theme repo as a dependency
   • Fallback to default theme if unknown theme?

Some random thoughts/ideas

• There's a wiki for formatters. There could be a similar community-maintained wiki page that showcases non-core themes that exist in their own repos. This could also guide the user how to "install" the theme (copy/paste, git clone, etc)
• hx --healtcheck indicates theme state
• alert user on startup if config uses retired theme. Let the user disable/silence the alert so they can mark it as read/understood?
  • and/or alert during build, rather than on every startup (can easily get missed though)
• An interesting observation is that neovim has something like neovim/nvim-lspconfig but not something similar for themes because there's no need? A counter-example, though: https://github.com/alacritty/alacritty-theme
• Have other projects encountered and solved this problem? IIRC wezterm (I don't personally use it) also provides 100s of builtin themes; I wonder if they have similar issues?
• Let's assume a popular theme like catppuccin is a core theme. Is there risk of drift/contention between helix and the upstream? Is there are an argument for having only "helix-authored" themes in core, even if that's just a rename of a popular theme like helix-catppuccin? Not super familiar with zed, but I saw there's a zed_onedark theme for example. IMO for pragmatism it makes sense to keep around some top themes in core for the medium term. Yes, eventually these may become old (see builtin vim themes), but that seems like something that can be resolved much, much later.

Disclaimer

I'm mainly just thinking out loud. Hopefully this is useful! I might have a naive understanding. This isn't exhaustive by any mean, and I'm sure there are issues I'm not thinking of. I'm also sure others have more experience moving something out of core than I do.

[markstos]

I don't think such a phased approach is needed for editor themes. It seems to sufficient to remove all non-core themes from the project with a changelog entry about where they can found. Even with the phased approach, eventually after an upgrade a theme could disappear, someone has to read the changelog about what happened and do something to keep using the old theme. Dropping the non-core themes immediately speeds up that process. I say that as someone who uses the unpopular jellybeans theme. It won't be a big deal if one day I have a follow a couple steps to re-install it privately.

[johnc219]

Yeah, I'm probably over-worrying about the "oh no i opened helix and my theme changed" scenario. That non-phased approach sounds much simpler and lighter, while not sacrificing much.

[rahil627]

you know what's right mikedavis. just off-load the themes to another repo, some official unofficial repo where things are far less guaranteed because.. open-source. Some place where PRs come easy. Let the theme people handle it. It would be nice if it's still part of the helix github organization, so it's easy to find. But if that's too annoying i understand too.

It would be nice if there's a command/feature to easily fetch from that repo, and perhaps any other repo, but that sounds like a whole 'nother thing, and gives me nvim config horrors of updating plugins. 😰

i'm happy as long as there's some place to quickly fetch/download a bunch of color themes and upload them too...

i personally enjoyed seeing new themes pop up over the development of helix, as from time to time, i like change, and i like to see if there's anything useful out there. Most do suck tho. Or look the same. Not enough love during the porting. The recent noctis theme (jellyfish, underwater vibes) is exceptional, showing off some great bolds and... actually based on a theme, really showing the beauty of helix and wezterm.

..maybe there can be one theme, like heisenburg, that just shows off the chaos of all possibilities of themes, and doubly-serves as a test theme? (the flashing text of heisenburg was one of my first memories of helix, lmao). It could become a well-documented template, a base for new themes.. flatwhite's highlighter style is great for debugging tree-sitter stuff, and actually unique too (i need to the make dark neon-highlighter version..).

anyway, def just toss it all to another repo for now! Just would need to find some stable folks to maintain/handle PRs..? Maybe can start by asking the people that made/ported the themes..

(and then, once it's in the community repo thing... can create various templates, particularly a 16-color template, to automate generating basic 16-color schemes for helix, likely similar to how wezterm likely does it.)

update: just added my theme 😜

[getreu]

Do you plan to organize a vote to obtain a ranking for the most popular themes?

[the-mikedavis]

It would depend on the policy we choose. If we move almost all themes (except the default and base16 themes for example) to another repo then there's no need for a vote. But if we keep a constant number then we should organize a vote

[getreu]

What about the following?

The themes are maintained a in different (Helix) repository with a dedicated maintainer, but shipped with the package/binary?

[markstos]

That's better than having them in core, but as long as the themes are centralized and shipped there a dependency on someone volunteering to maintain many, many themes they don't use.

What would happen if that volunteer role is not filled and there are compatibility issues to fix with themes before the next release goes out? Either someone from the core team has to fix them all, or that point they need to stop shipping all the themes.

That's why I think it's more sustainable for maintenance to only ship a few themes while making it easy to find and install more.