Compile with vim-friendly settings about lush.nvim

[rktjmp]

Fixed in aaa9a4c

You may still need to do some manual touch ups. compile won't include code to clear existing highlights (even though that was listed as an option, it was an error in the docs) because it relies on checking some vim-runtime settings that I don't want to pollute down to that layer.

This really only needs to be done if you're hot-reloading like :Lushify does, so it is likely not a problem if you're targeting vim.

See instructions, specifically compiles exclude_keys option.

lush.nvim/doc/lush.txt

Lines 549 to 599 in 3a188f1

	--------------------------------------------------------------------------------
	Manual Toolchain *lush-manual-toolchain*
	If desired, you can manually parse -> compile -> apply your lush-spec.
	>
	local lush = require('lush')
	local parsed = lush.parse(function() return { ... } end)
	local compiled = lush.compile(parsed)
	-- may want to manually insert clearing existing highlights here
	-- see lush.lua, search for insert_force_clean for an example
	lush.apply(compiled)
	<
	Parse *lush-manual-toolchain-parse*
	Accepts a lush spec and returns a parsed lush spec.
	Accepts no options.
	>
	local parsed = lush.parse(function() return { ... } end)
	<
	Compile *lush-manual-toolchain-compile*
	Accepts a parsed lush spec and returns a list of vim commands to apply the spec.
	Note: You may wish to prepend commands to clear existing highlights before
	continuing.
	See lush.lua, search for insert_force_clean for an example.
	Accepts the following options:
	- exclude_keys: list of strings, where each string matches a lush spec key to
	exclude from the compiled command.
	Valid keys: fg bg sp gui blend
	>
	local compiled = lush.compile(parsed, {exclude_keys = {"blend"})
	<
	Apply *lush-manual-toolchain-apply*
	Acceps a list of vim commands to pass to the interpreter.
	Accepts no options.
	>
	lush.apply(compiled)
	<
	--------------------------------------------------------------------------------

lush.nvim/lua/lush.lua

Lines 15 to 31 in 3a188f1

	local insert_force_clean = function(compiled_ast)
	local clean = {
	"hi clear",
	"syntax reset",
	"set t_Co=256",
	}
	if vim.g.colors_name then
	-- 'hi clear' will clear g:colors_name, so restore if it existed
	table.insert(clean, "let g:colors_name='" .. vim.g.colors_name.."'")
	end
	for i, c in ipairs(clean) do
	table.insert(compiled_ast, i, c)
	end
	return compiled_ast
	end

[rktjmp]

As it happens, was also asked yesterday, #29

Lush is a neovim plugin that happens to have some vim compatibility, basically by accident.

Why I am hesitant to just throw the option in (as you say, it's not a hard code problem) is sort of two fold:

• the API should be extensible and clear
  • Adding a key here, a key there, etc is death by a thousand cuts for an API, before long you're in php.
  • I hate having API's change underneath me, and no one really comes back regularly to their vim plugins to check its up coming changes and there's no lock file equivalent (maybe you could use semver branches I guess).
  • So it needs some thinking on whether just adding a "vim8_mode" key is ok, vs a feature toggle set (might be best, to support gui client options too?), vs supporting different compilers
• Adding one rule to drop blend isn't too complicated, but I can imagine if vim starts using a different key name for gui (or more likely, use a different key for blending, or even a different blend value type), people may expect Lush to support that too. Then I'm having to support something I don't use (vim).

That's not to say no, just why I feel a bit uncomfortable adding it... Obviously it would be useful to people so it will probably appear in some form.

The readme definitely needs a warning about blend options right now at any rate.

[milisims]

Huh, sorry for missing that! I think I just searched for 'compile'.

You do make really good points about why not to include it. For me, it would have been helpful to have:

1. a clear path for how to get the compiled lines in vimscript or lua
2. a list of known incompatible options (i.e including a disclaimer that this may be extended without your notice)

That way you don't need to extend the API, and I would have known what I needed to do. Filtering some
strings pretty programming 101, so the user should be able to understand what to do from there.

Didn't mean to close the issue, sorry!

[rktjmp]

Likely to just include a strip option to compile.

lush.compile(spec, {
  strip = {"gui",  "blend"}
})

That way I can pretend it isn't for Vim 👀

strip
drop
remove
dump
dont_include
exclude

Probably exclude. Maybe exclude_keys.