Skip to content

feat: use pre-built lua files for Neovim#235

Closed
s-cerevisiae wants to merge 1 commit into
zenbones-theme:mainfrom
s-cerevisiae:push-qovpxypwzzpp
Closed

feat: use pre-built lua files for Neovim#235
s-cerevisiae wants to merge 1 commit into
zenbones-theme:mainfrom
s-cerevisiae:push-qovpxypwzzpp

Conversation

@s-cerevisiae
Copy link
Copy Markdown
Contributor

@s-cerevisiae s-cerevisiae commented May 10, 2026

This removes the runtime dependency on lush.nvim for users who don't need palette customizations, cuts down the load time from ~10ms to ~2ms on my machine, and gives me back Neovim-exclusive highlights without adding unused names to the Vim side.

Maybe there's better name than lua/*/prebuilt.lua though, suggestions welcome.

Fixes #230
Fixes #98

@s-cerevisiae s-cerevisiae marked this pull request as draft May 10, 2026 10:55
@s-cerevisiae s-cerevisiae marked this pull request as ready for review May 10, 2026 10:59
@mcchrish
Copy link
Copy Markdown
Collaborator

Thanks for this! However I'm more open to tackling caching solution.
Unfortunately, I don't have time to implement it myself but willing to do PR reviews.

@s-cerevisiae
Copy link
Copy Markdown
Contributor Author

s-cerevisiae commented May 10, 2026

@mcchrish My personal opinion on this is that AoT compilation is better than caching. It reduces runtime dependencies, is less complex and is very easy to reason about: in doubt check the actual files. I use Fennel in my Neovim config which also needs a transformation step, and every solution alive right now have switched to compile ahead and check-in instead of caching (because of performance issues and bugs).

@mcchrish
Copy link
Copy Markdown
Collaborator

Those are true. I do want the possibility of improving performance and still allow configuration.
That's why caching was the first thought I had, and is already done by more popular theme.
But it's definitely more complex.

@s-cerevisiae
Copy link
Copy Markdown
Contributor Author

s-cerevisiae commented May 10, 2026

still allow configuration

Palette customization is still the same as before, just slower than using the prebuilt versions. I'm doing slight customization to the color groups, but in the vim way because I don't touch the colors definitions.

What's your opinion on letting users compile their customized variants into their colors/? For example with a :Shipwright-derived command that fits in update hooks of plugin managers.

already done by more popular theme

Sounds interesting, any examples?

Tbh my main focus is to remove the lush.nvim dependency from daily use. I can keep using my fork if you have different opinion though.

@mcchrish
Copy link
Copy Markdown
Collaborator

https://github.com/folke/tokyonight.nvim
https://github.com/rebelot/kanagawa.nvim
Are some example.

What's your opinion on letting users compile their customized variants into their colors/? For example with a :Shipwright-derived command that fits in update hooks of plugin managers.

Yes, I like this approach. In some themes, it's a config cache = true or compile = true. Or can be done via user command.

@s-cerevisiae s-cerevisiae marked this pull request as draft May 10, 2026 13:52
@s-cerevisiae
Copy link
Copy Markdown
Contributor Author

s-cerevisiae commented May 10, 2026

Okay I see. Now I get the idea of what a "caching" theme looks like and I just realized the plugin has actual options without touching the lush bits. Maybe I'll try to improve this one or think of a better solution when I have more time.

@s-cerevisiae
Copy link
Copy Markdown
Contributor Author

Superseded by #236.

@s-cerevisiae s-cerevisiae mentioned this pull request May 17, 2026
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Discoloration of variable names upon zenbones_compat = 1 Cache generated specs

2 participants