rktjmp / lush.nvim

Create Neovim themes with real-time feedback, export anywhere.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Clearing default `gui=` settings.

ndreas opened this issue · comments

With the recent changes on how the gui= parameter is handled, it is no longer cleared if left empty. In addition, there is no way to set gui=NONE.

Neovim defines a number of default gui= settings, for example for hi TabLine, and I have had to add gui = "nocombine" to the rules that I want to clear.

Are you able to provide a small example of how you're doing things?

Are you mixing gui= and bold=true etc? That's not recommended but if you are we can discuss ergonomic improvements perhaps.

If I define my group TabLine { fg = red }, the underline is removed as expected, if I inherit from it I can set gui="" or gui="NONE" to clear any that I do intentionally set. If I never define TabLine I can't inherit from it so that seems like a non-factor.

Perhaps there are groups that naturally link to tabline, or I guess text inside a tabline?

Having trouble reproducing or understanding the issue.

I wonder if it's due to the way I build my theme. I use TabLine { bg = dark_grey, fg = grey }, and then I build using a custom Shipwright file. The build uses require("shipwright/transform/lush").to_vimscript which to my eyes does not respect NONE here: https://github.com/rktjmp/lush.nvim/blob/main/lua/shipwright/transform/lush/to_vimscript.lua#L42

Files are here: https://gitlab.com/ndreas/vim-config/-/tree/main/lua/ndreas-theme
I don't use Lush dynamically, but rather build my theme into colors/.

Ah yes, the vimscript exporter is kind of "best effort", not surprised to see it have a rough edge.

Previously, if gui was not set, it would end up as gui=NONE in the viml

https://github.com/rktjmp/lush.nvim/blame/0517452a74fe25f6a62cacb75e4b25bb1dcb2803/lua/shipwright/transform/lush/to_vimscript.lua#L53-L55

Can you try the fix-91 branch, I think that will do what you want and restore the old behaviour.

Yep it works great!

Fixed in 6923cce

Thanks for reporting the issue!