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.

[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.

[James-Firth]

I'm sure anyone, myself included, will be slightly inconvenienced if our favourite themes don't make the cut.

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...