../neovim-plugin-convention

Automation opportunities in the neovim plugin ecosystem

This post is written with the intention of serving as a concrete starting point for a discussion on how plugins can expose their functionalities/settings to either neovim or a third party.

NB: if you are looking for the exposure of other metadata like package dependencies, let me redirect you to previous post,

Why do you ask ?

A similar example in neovim I am proud of is how neovim options are exposed and can be fuzzy-searched via :Telescope vim_options (though I preferred how this outdated plugin allowed to fuzzy-search on the options description). Lookup :nvim_get_option_info and src/nvim/options.lua if you are curious).

Before starting, let's sum up some design goals as well as the non goals:

Conclusion

I am no plugin author so I may lack the proper perspective, yet I've taken on to provide this starting point (nothing official !), to kick off the discussion.

First off, the format choice, for the reasons listed by justin here, I think lua is the least restricting choice: no external dependencies. etc.

The plugin ecosystem indicates a striving lua trend (check github trends), and fennel, teal plugins can generate lua. Lua is easy to generate too and in most cases it will be created manually anyway.

{
	-- single increasing number to detect an outdated format
	-- if unsupported format
	version = 42,
	-- list of available colorschemes, can this be automated from colors ? 
	-- check telescope ?
	colorschemes = {
		"gruvbox-256",
		"gruvbox-trueguicolors"
	},

	-- 
	user_options = {
		type = "ro", -- readonly
	ro_ = {

	},

	-- expose mappings between a provider name and a possible value
	providers = {
		[" "] = "",
		["clipboard" = ""
	}
}

/plugins/ /neovim/