Closed rktjmp closed 2 years ago
[ ] Adjust apply to accept any key given in spec and pass that on to nvim_set_hl?
- Better maintenance for Lush as features are automatically supported
- Breaking change due to
gui
property.
maybe add to_hl
or something similar to op_fns
as well?
That would be a bit frictional I think.
Currently I am thinking there will be two (!!!) breaking releases.
The first will just require 0.7 for nvim_set_hl
compatibility, not a """huge""" deal. This will retain all the same spec behaviour, and add no additional key support.
The second may drop gui
in favour of accepting any key in the spec and just forwarding on what it's given. Not 100% on this yet as I don't really know if needing italic = true, bold = true
is any better than gui = "italic, bold"
. It's closer to nvim's true API but not exactly any more ergonomic and Lush is already an abstraction anyway. I could probably inject some state into the spec env so you could go Normal {fg = ..., bold, italic}
but then you'll have mixed key tables which can be annoying to work with, while also forcibly clobbering any user-defined variables with the same names, not great, but also having some protected keywords isn't too crazy.
There's also a secondary concern with "any keys" for inherit groups,
-- via gui
A { gui = "italic bold underline" }
B { A, gui = "italic"} -- automatically sets bold=false underline=false, omission implies false
-- via any-keys
A { italic = true, bold = true, underline = true}
B { A, bold = false } -- would have to set the inverse, which feels less intuitive to read,
-- note that underline = true here because the value would be inherited
Typing this out is probably leading me to just retain the existing gui=
style and have any extra keys require a patch. New formatting modifiers are probably pretty rare all things considered (nvim added blend
and the others have probably been in vim since the 90s?). The "patch" required would be basically adding one call to maybe_set("superduperunderline")
and updating a test so not exactly a huge burden, but it is a bottleneck.
None of that's set in stone though, open to criticism.
Closing for https://github.com/rktjmp/lush.nvim/pull/88 with proper changelog.
Updates Lush to use the new
nvim_set_hl
API, which is potentially quite a bit faster, relatively speaking.In practical terms, themes go from ~1-2ms application to 1-0.5ms application, depending on the themes size.
[x] Push doc-fixes upstream?
[x] Update shipwright generator
to_lua
shipwright now exports just a list ofGroup = {fg = ...},
lines for manualpatch_write
into your own table variables. You should then manually iterate the list andnvim_set_hl(0, <group>, <attrs>
.[ ]
Adjust apply to accept any key given in spec and pass that on to nvim_set_hl?Better maintenance for Lush as features are automatically supportedBreaking change due togui
property.[x] Supports direct format boolean modifiers
gui
key (which accepts any value given above as a string (gui = "bold italic"
), direct bools will override any gui values.[x] update docs
[ ] How to provide support for older nvim users
if nvim-0.6 then cmd(group_to_cmd) else nvim_set_hl(group)
in a shipwright exported lua file.[x]
hi clear
via lua?[x] Drop support for compiler plugins