A colorscheme “framework”

[mrjones2014]

Sometimes I come across another theme I want to try. Example is I really really like the oxocarbon.nvim theme.

But onedarkpro.nvim does so much stuff that I’m hesitant to actually drop it for another theme. So something I’ve done a few times is, look through the source code, extract the color palette, and just override every single color of onedarkpro.nvim with the other theme’s color palette through config.

It’s kinda funny lol but it unironically works great. I wonder if there is an opportunity here to split a “core” out of onedarkpro.nvim and make a “colorscheme framework” that other colorscheme authors can use, setting colors but still getting all the kick ass features of onedarkpro.nvim, or that users could drop into their dotfiles and make custom themes.

I don’t know if this even makes sense or not. I just had the thought randomly and thought I’d start brainstorming.

[olimorris]

Hahaha. No this totally makes sense!

I too thought about this some time ago. When I was messing around with terminal colours. Could exposing a theme via the config make it easier?

[mrjones2014]

So I guess what I'm saying is, sometimes just copying the palette from another theme doesn't quite work because the highlight groups are configured differently.

But what onedarkpro.nvim offers in terms of features is bringing a lot to the table -- colorscheme caching, plugin support, etc.

I guess what I'm looking for is a way to load a different theme into Neovim, and somehow have onedarkpro.nvim read all the current highlight groups, and sort of "export" that to a file that could then be plugged back into onedarkpro.nvim's configuration to replicate the same colors, but with the caching and etc. of onedarkpro.nvim also. Does that make sense? 🤔

[olimorris]

Yep it does. It's actually a really neat idea for a plugin. I created my own colorscheme because I wanted the level of customisation that I now have in onedarkpro.nvim.

You could ask OneDarkPro to just read all of another theme's highlight groups with the vim.api.nvim_get_hl_by_name command. Then you could overlay the user's config, compile and cache it as we do currently. You'd still get the ridiculously fast load times too.

Given how the plugin is currently structured, it could be straightforward. I need to sort out autocmds this week and patch nightfox's color library but I'll likely riff on this after that.

[mrjones2014]

Sick, let me know if you need any help ❤️

happy to help with PR reviews or contributions

[olimorris]

Been thinking about this in a massive way. Will add you to a private repo in the coming days. Got lot's of ideas on how this could work but will flesh out the API with you first

[mrjones2014]

That sounds awesome!