Formalize an extension specification: make configuring neovim as easy as vscode

[mjlbach]

It would be nice to facilitate GUI based neovim configuration and it should be possible to make this as easy as vscode. In order to support that, we need several components:

1. A central manifest of plugins (vim-awesome?), with some categorization (github tags?) and sorting (stars?)
2. A model template for plugins (https://github.com/norcalli/neovim-plugin) with recommended practices (don't map keys by default is probably the big one)
3. A template for a specification.json (originally *.lua, but now I agree with @smolck) which exposes the available options of the plugin, with optional recommended default keybinds for example, in a way that a GUI based client can offer menu based configuration of the plugin. This is similar to a package.json from a vscode extension. Final name tbd.

I'm making this as a tracking issue, as it gets brought up on IRC regularly and it would be nice to get feedback from plugin authors. I don't believe core should implement the GUI based configuration of neovim, but rather provide the infrastructure for plugin/GUI authors .

[bew]

Another thing you didn't mention and I think is important, is to try to promote semver (https://semver.org/) to version plugins. This would be the first step (with the specification.lua) to have plugins dependent on other plugins..
To ensure breaking changes are not necessarily auto-installed (this would need support from plugin managers, maybe with a builtin version comparison system to avoid re-implementing that in every pkg manager?) (for plugins going from neovim stable to 0.5.0 by default)

[glacambre]

I don't believe core should implement the GUI based configuration of neovim, but rather provide the infrastructure for plugin/GUI authors .

nvim_get_all_options_info has existed for a while now and AFAIK there aren't any plugins taking advantage of it to provide easy/graphical configuration of default Neovim options. Extrapolating from this datapoint, I think nobody is going to build a GUI for configuring plugins even if an API was implemented.

IMO the problem is that writing such a plugin requires expert knowledge, but somebody with expert knowledge is very unlikely to want such a tool for themselves as they already have configured neovim to their liking. There's a chiken and egg issue here.

On the other hand, this argument could be applied to plugin managers but doesn't seem to hold there as there are a lot of plugin managers, some written by very experienced vim/neovim users. I would posit that this might be for two reasons:

• The effort required for writing a plugin manager is lower than the effort required for writing an easy/graphical configuration tool, but I could be wrong.
• While a plugin manager is automation (so worth implementing as it saves time in the future), a configuration tool is not (most of your usage is going to be interactive). So plugin managers save more time than configuration tools.

So unless core maintainers are willing to bear the burden of implementing and maintaining a tool consuming this data, I doubt implementing such APIs will actually be worth it. (This doesn't mean that I don't want to see this implemented, I'm just trying to do cost/benefit analysis :) ).

[shadmansaleh]

@mjlbach Point 1 agreed . But point 2 and 3 though I don't think it's possible .

1. There's no way you'll get everyone onboard with the template . Specially already existing vim plugins . Even if you got all the newly written lua plugins follow a template . The vim plugins or or vim compatable plugins won't use this in most cases . That defeats the entire purpose of using it to ease configuration.
2. You can't drop compatability for plugins that don't follow it because the biggest portion of plugins are vim/vim_compat plugins . And that's not changing anytime soon .So the point 2 and 3 aren't enforceable .

The effort required for writing a plugin manager is lower than the effort required for writing an easy/graphical configuration tool, but I could be wrong.

@glacambre It's not that hard to make a framework for it . But IMO real issue is you'll to maintain a huge database of plugins and their configs to make it even effective . Which is just no one willing to do .
Also if it's a plugin it's kind of useless as this kind of plugin will only be useful to a newcomer. Now how is this person suppose to find and install in plugin to configure his/her editor . Like you said chicken and egg 😆 . This might only make a bit sence in core . But again huge maintainability burden makes it not worthy of the time.

But I think adding a gui to configure neovim it self not plugins in core might be worth it for new users 🙂.

[smolck]

1. vim-awesome's development is pretty stagnated it seems, for one reason or another, even after some discussion/work last year to change that (see Offer to join org and help maintain this vim-awesome/vim-awesome#390). Perhaps it could be revived, but if a true "central manifest of plugins" is to be created, it should probably be under the neovim org and domain name so it's official? That could potentially be done with vim-awesome, but might be worth a full rewrite (not in Python, preferably :P); either way, I'm happy to help out as/where I can.
2. Agreed.
3. This would go along with point 2, right? So the plugin template would have a specification.json? Also, I say .json and not .lua because JSON is much easier to parse than a Lua file, at least from a GUIs perspective. There's really no need to use Lua for a specification file anyways (except perhaps for consistency, which isn't that great of an argument IMO). Also, +1 to what bew said about semver.

@glacambre FWIW, I actually don't think it would be that hard to create a config manager, with a little setup. If I was going to write a configuration manager in uivonim today without any of these changes mj listed, first I would probably write a plugin (or single Lua file so people can copy-paste it w/out installing a plugin) to enable configuration via a JSON file (let's call it init.json), and then I would write the GUI code necessary to emit/edit such a JSON file, reload it as necessary, etc. That doesn't seem so hard to me, unless I'm missing something?

Then assuming plugins have a clear specification.json file I can parse, configuring plugins would be easy (or at least fairly straightforward) to add to that. Any plugins that don't have that wouldn't be configurable from the GUI, and people could submit PRs to those plugins to make it possible.

@shadmansaleh As far as your disagreements go, the point wouldn't be to only support plugins using the template, but instead to provide a template that plugins which want to be supported (viewable, maybe installable, etc.) by the (GUI) config/plugin managers can use. Plugins that didn't have a specification.json for example would still be usable by Neovim, just not usable by the (GUI) config/plugin managers.

[mjlbach]

I'll preface this, by saying I am not the kind of user that this functionality is targeted at.

try to promote semver (https://semver.org/) to version plugins

@bew Sure, this could be added to the template, but I don't see it as a hard requirement for implementing the idea. Auto-updating plugins is not necessarily within scope.

[paraphrased], nvim_get_all_options_info has exited for awhile, people capable of making this won't use it so have little incentive to make it, , this argument could be applied to plugin managers

I would, for now, advocate putting aside the question of plugin managers (see also above) and focus on supporting just one (I'd advocate for packer) but this is not part of the specification, but an implementation detail of the GUI based configuration. I agree for this to work, it has to all be done in coordination with a GUI author, a plugin author, and a core member (hence the thread, which now has all 3!). We need an end to end demo for people to "buy-in"

There's no way you'll get everyone onboard with the template

There's no need for people to get on board with the template, we can incrementally have people adopt certain formalisms which make their plugins compatible with the spec, and if they don't the situation remains exactly as it currently is. Honestly the template is less important than the package.json/lua I brought up in point 3.

You can't drop compatability for plugins

Of course, that would never happen/be advocated for. I want to emphasize that this would be opt-in, and probably require no changes in neovim core.

Perhaps it could be revived, but if a true "central manifest of plugins" is to be created, it should probably be under the neovim org and domain name so it's official?

I'm pro this, but I think other people will only be pro this if it's done in a way that requires no manual intervention (maybe through a github tag?).

So the plugin template would have a specification.json? Also, I say .json and not .lua because JSON is much easier to parse than a Lua file, at least from a GUIs perspective.

Yes, or we provide a mechanism to parse the *.lua I know this would drive some people crazy, but I imagine it could be useful to have the *.lua have some internal logic/linted by sumneko.

I agree with the entirety of smolck's post, and uivonim would make an excellent candidate for piloting some of these ideas.

[mfussenegger]

I think there could also be some extra goodies that provide incentive for plugin authors to follow these standards.

For example, you could have an api in nvim to register available options in a declarative way. That could include type information and available options. Then users could set options via vim.opt.ext.<name>.whatever_dont_bikeshed_about_syntax_details_just_yet and you get automatic validation, completion and other goodies.

These options could also be included in nvim_get_all_options_info.
You could have functionality to generate docs for them
You could have functionality to generate a specification.json.

All this for little effort on the plugin author.

There's also already some code around to generate vim help docs from a lua docstrings. One could take that and extend it with some markers - for example with a keymap hint, to mark a method as "intended for use in a keymap". Then the vim-help docs generation could optionally include a section with recommended keymappings - generated from the code docs.
This information could then also flow into the specification.json.

[shadmansaleh]

opting in with specification.lua/json makes sence.

I actuly don't know much about guis . But can't guis use lua interpreter embeded in neovim to evaluate specification.lua . If it can lua is a better option IMO :) . Also will there be any tui version or gui only ? I actually tried making a plugin like this last time teto said about ui for configs . It got stuck in experimental stage months ago 😅

[smolck]

I actuly don't know much about guis . But can't guis use lua interpreter embeded in neovim to evaluate specification.lua .

You could evaluate it, sure, and theoretically get access to the outputted module or string or whatever, but still, I think my vote goes to JSON. I love Lua as much as the next guy, but there's really no need for the extra power it provides here. Plus, you can always just generate specification.json with Lua (which might be what ends up happening in the template anyways).

There's no real reason Lua couldn't be used, as mjlbach said we could provide a parser for the file, but to me that just adds more work for the GUI/plugin author in order to figure out how to use that etc., where if it was a JSON file it would be easy since basically every language imaginable (or at least the ones that would be used for a GUI or plugin) has a JSON parser.

[ruifm]

Regarding the lua vs json for the spec file, I actually believe that it can not possibly be json.

Several lua plugins have options that functions and afaik, you cannot enconde that info in json (only bools, decimals, strings).

[clason]

Two comments:

1. Yes on semver -- there's so many issues that start (and end) with "are you on latest master? when did you last update the plugin?". Even just putting a default (mandatory?) version field in the specification goes a long way.

2. For the "plugin manifest", json probably makes more sense than Lua since you don't need to execute it. (You don't need to store functions in it; string keys with function names would be sufficient.) Providing a plugin template (like norcalli's) that auto-generates it from the Lua code (or, rather, docs) would sweeten the deal.

3. Tree-sitter. There's already tooling being developed to auto-generate (vim) docs from docstrings; that could (and should) be leveraged here as well.

4. I would focus less on configuration GUI and more on a standard interface/manifest standard/API and provide tooling (in core) to make it as easy as possible to programmatically generate and interact with it. Then plugin managers and config plugins that hook into it would naturally spring up.

TL;DR: "If you build it (well), they will use it" :)

[smolck]

Several lua plugins have options that functions and afaik, you cannot enconde that info in json (only bools, decimals, strings).

@ruifm Hmm, initially I would agree with you, but after some thought it shouldn't really matter. I'm imagining something like this:

{
    "options": {
        "some_opt_needing_function": {
            "type": "function",
            "default": "function() print('here's lua code') end"
        },
        "other_opt": {
            "type": "string",
            "default": "helloworld"
        }
    }
}

Here, the GUI can decide what to do for some_opt_needing_function: generate Lua code, make the user deal with that, just run the default code by putting it in a Lua file, etc. You could do this in Lua too, of course:

{
    options = {
        some_opt_needing_function = {
            type = "function",
            default = function() 
              print("here's lua code")
            end
        },
        other_opt = {
            type = "string",
            default = "helloworld"
        }
    }
}

But if a GUI parsed this to use it (as it would need to), it would still just have the function() ... end part as a string, and then have to decide what to do with it. It's just easier to get the information w/JSON for the reasons I stated above (easy to find a JSON parser in x language).

This is kind of an edge case though, for config options like this it'd probably be better to just write the config yourself w/out any GUI helper (analogous to having to write a VSCode plugin in JS for more complicated configuration).

[clason]

I think this is an important point that bears repeating: this is about plugins advertising their possible options/commands/keymaps, not about configurations. That should always be in Lua (assuming Lua plugins), and init.lua should take precedence and GUI config should reflect/sync with that.

(Nightmare scenario would be a GUI that has a parallel "Settings" page that overrides some but not all of my TUI config...)

[hadronized]

Regarding the lua vs json for the spec file, I actually believe that it can not possibly be json.

Several lua plugins have options that functions and afaik, you cannot enconde that info in json (only bools, decimals, strings).

This is a problem of encoding entirely up to the plugin, not to the platform. You have to explain what you encode. Any value can be encoded as a function if you want (32 can be encoded as the Lua function function() { return 32; }), and the other way around is possible but is left to the plugin to architecture correctly to enable that. If you need to expose a function to the user, it means that you need to refactor the code of the plugin so that the function becomes a value — that would dispatch the actual function inside the plugin.

“Selecting” a function is configuration and should really be only selecting a value. You can imagine a <select> HTML tag: it’s just a basic string that would represent a function.

[koalp]

Another thing you didn't mention and I think is important, is to try to promote semver (https://semver.org/) to version plugins. This would be the first step (with the specification.lua) to have plugins dependent on other plugins..

I think that having a standard way to advertise dependencies and versions for plugins would be a very useful feature.
However, It would raise the problem of dependency hell, but since the plugin management is delegated to external plugins, this would not be a neovim issue.

Using json instead of lua would also make it easier to adopt for non-lua plugins.

[teto]

Let's open different issues for semver and the collection of plugins which are orthogonal issues.

As I see this, it doesnt require any change in neovim side, or enforcing anything. The neovim org can just act as a coordinator to agree on a standard. I dont think it will be too much of a hassle for plugin authors, on the contrary. As we already some high-profile plugin authors in the neovim community, I am optimistic we could bootstrap the thing reasonably well.

The difficulty is in coming up with a format that doesn't constrain authors too much, is practical and that wont change much in the future. We should have a very clear roadmap of how it will evolve but we can start small with just exposing options, and expanding the standard little by little.
And also to encourage adoption of the standard, people should be able to benefit from the new standard straightaway, modifying options via an interface similar to :Telescope vim_options maybe ?

As for the format itself, it should contain at least default value, type, name of the option, some description (help could be generated from these later on ?).

One possible inspiration can be

neovim/src/nvim/options.lua

Line 85 in b227ced

short_desc=N_("allow CTRL-_ in Insert and Command-line mode"),

[mjlbach]

Where would the best place to develop this be? Should we make a new repo under the neovim org, something under nvim-lua, create a new org itself (nvim-packaging?)?

[teto]

if we want to formalize we could create neovim/nvim-rfc but for now, a PR in this repo for runtime/doc/plugin_spec.md could do (we dont have to merge that, just useful to iterate) ?

@clason I think it is you who is skeptical about generating a vim config; https://github.com/teto/vim-config is a 1-hour project written in a train a while ago but I think it is a good approach, just have the tool handle its own init.generated.vim and from your init.vim source it. I really hope someone can do something along those lines. Such a GUI could be opiniated and for instance not disclose the underlying plugins, just expose features [ ] enable indent guides and then in background install https://github.com/lukas-reineke/indent-blankline.nvim/.

[clason]

@teto 👍🏻 on the PR, that seems like the best/easiest option for now.

And that's a nice project, but I remain skeptical that this can be made sufficiently robust to survive in the wild ;) (To be more precise, I don't doubt that such a config manager could work on its own; the difficulty comes when you want it to work in combination with manual init.vim/init.lua changes -- which you may disallow -- or other config managers: for example, a plugin like yours for TUI and a GUI having their own native implementation. Such interoperability would be the point of a standard, after all.) But I'm happy to be convinced otherwise :)

[teto]

There is always the possibility to mess up, but that's true even without it. My guess is that if you have parts of the config handled by the generator, then your manual changes will change something else so both shouldn't conflict. This can be very useful for beginners that dont want to fiddle with the config from the get go, one of the goal of neovim was to make vim more approachable as well. So first they can focus on learning vim modes etc and once they are comfortable with vim mappings they can take inspiration from the generated config and write their own init.vim.

[neovim-discourse]

This issue has been mentioned on Neovim Discourse. There might be relevant details there:

https://neovim.discourse.group/t/lua-plugin-startup-time/937/11

[neovim-discourse]

This issue has been mentioned on Neovim Discourse. There might be relevant details there:

https://neovim.discourse.group/t/leveraging-telescope-fzf-for-plugin-search/949/2

[neovim-discourse]

This issue has been mentioned on Neovim Discourse. There might be relevant details there:

https://neovim.discourse.group/t/leveraging-telescope-fzf-for-plugin-search/949/4

[teto]

I've written something that is not related to the configuration aspect but the distribution aspect, i.e., package dependency management: https://teto.github.io/posts/2021-09-17-neovim-plugin-luarocks.html
If dependency installation can be automated, then we've already simplified things a bit and it becomes possible to install plugins via a palette like in sublime text or vscode.

[justinmk]

A key advantage of emacs/vim is that making a plugin is very easy. Bureaucracy defeats that.

So any "spec" should be very simple and "flat".

Could be a matter of defining conventions (including the existing conventions: 'runtimepath' layout, etc.), which can then be passively discovered by Nvim. E.g., if a plugin defines lua/foo/config.lua , Nvim can require('foo.config') to get its config, and inspect the returned structure.

No need for goddamned JSON.

3. the plugin template would have a specification.json? Also, I say .json and not .lua because JSON is much easier to parse than a Lua file, at least from a GUIs perspective.

Lua is easier to read for humans. And we already have a parser. Any third-party tools that need to "parse" the Lua can require() it. For security, use a container or AWS Lambda, idk.

Or just parse it. Luacheck implements a Lua parser. Parsing is not a reason to add JSON to the vim plugin ecosystem.

VSCode gets a lot of things right but much of its decisions are accidental or constrained by the JS ecosystem. Don't need to copy them.

For example, you could have an api in nvim to register available options in a declarative way

"Register" is active; "declarative" is passive. Passive is good. Active is bad. nvim_register_my_plugin() is active. A lua/foo/config.lua file that is discovered and returns a spec map, is more declarative.

[famiu]

I would prefer a .lua file over .json as well cause some configuration options that require a function as their value would simply just not work in JSON. And I don't like the idea of using a JSON string to hold Lua code which is then parsed by a Lua parser, too complicated imo

[hadronized]

@famiu if you require a function to be passed as configuration, then you should move the function to the plugin space and expose a configuration option to the user to select that option.

[famiu]

@famiu if you require a function to be passed as configuration, then you should move the function to the plugin space and expose a configuration option to the user to select that option.

I'm not really getting what you mean. Could you please provide an example

[bew]

@famiu if you require a function to be passed as configuration, then you should move the function to the plugin space and expose a configuration option to the user to select that option.

If I understand this correctly, you mean that the function should be written by the plugin author and stored in the plugin itself, and only giving options to choose from to select a behavior?
But that doesn't work for user-defined functions 👀 Plugin authors can't support all use cases / other plugins / ...
I thought plugins where supposed to be extensible, how does that fit in?

[famiu]

@famiu if you require a function to be passed as configuration, then you should move the function to the plugin space and expose a configuration option to the user to select that option.

If I understand this correctly, you mean that the function should be written by the plugin author and stored in the plugin itself, and only giving options to choose from to select a behavior?
But that doesn't work for user-defined functions eyes Plugin authors can't support all use cases / other plugins / ...
I thought plugins where supposed to be extensible, how does that fit in?

Yeah, exactly

[hadronized]

@famiu if you require a function to be passed as configuration, then you should move the function to the plugin space and expose a configuration option to the user to select that option.

If I understand this correctly, you mean that the function should be written by the plugin author and stored in the plugin itself, and only giving options to choose from to select a behavior?
But that doesn't work for user-defined functions eyes Plugin authors can't support all use cases / other plugins / ...
I thought plugins where supposed to be extensible, how does that fit in?

You can always find a way. Code shouldn’t be user facing, it should only be about configuration. If you require people to provide functions, then it means your plugin lacks configuration segregation. And your plugin breaking in that case doesn’t mean the pattern is bad, it shows your plugin is not architectured correctly instead. Look at what other editors do, like Atom or VS Code. They don’t ask users to push « functions » to configure a plugin.

[bew]

Look at what other editors do, like Atom or VS Code. They don’t ask users to push « functions » to configure a plugin.

And that's one of the reasons I don't use them...

[mjlbach]

I'll chime in since I opened the issue.

A key advantage of emacs/vim is that making a plugin is very easy. Bureaucracy defeats that.

This isn't about bureaucratization of plugin developments. Vscode has extremely detailed documentation on how to create an extension, including codifying certain conventions about how things are structured (see https://code.visualstudio.com/api/get-started/your-first-extension) and example templates for creating different types of extensions. For every plugin developer that thinks developing a plugin is easy, there's a novice who has absolutely no idea what a neovim plugin even looks like, and I'd rather there be examples/tutorials to guide people than continually pointing people to blog posts or to infer by dissecting popular large plugins.

Establishing and documenting conventions can be useful as the number of plugins scales. Already there are keybinding collisions because certain plugins map keys by default. Establishing entry points for configuration (see the proliferation of a setup{} entry point), and conventions around configuration could be valuable.

No need for goddamned JSON.

I don't think the tone is necessary. Many users have been asking for/interested in creating a searchable repository of vim-plugins akin to the vscode extension marketplace, and I think it is valuable to establish convention here.

While there could be an intermediate lua -> some plain-text format step as part of indexing a plugin, the point with a plugin.json (or name whatever) was to have a plain-text indexable format that could describe the metadata of a plugin, including things like the category, versioning, repo, maintainer, etc. Extending this to things like mapping the available options (similar to how vscode uses it), would be an area of discussion (this purpose I mention in the original issue).

I should also mention, I only opened this issue because of feedback from aspiring plugin developers, and active plugin developers like @phaazon who have quite popular plugins, and because I wanted there to be a central point of discussion.

[hadronized]

Look at what other editors do, like Atom or VS Code. They don’t ask users to push « functions » to configure a plugin.

And that's one of the reasons I don't use them...

In terms of UX they are pretty much examples to follow, and I’m talking end-user here, not plugin authors using other plugins. After all it’s a shift of mentality. If people don’t really care about providing a better UX for end-user then yeah, why are you commenting on this issue?

[famiu]

It's not that Atom or VSCode don't require users to put functions, it doesn't even allow the user to put functions even if the user wanted to, which hinders the ability for configuration massively. To me, User-friendliness does not mean stripping away every bit of functionality and customizability, it's to not require the user to modify the things they don't want to or need to, but also allow them to in case they want to.

If you require people to provide functions, then it means your plugin lacks configuration segregation

Then kindly tell me how someone's supposed to have something like a custom statusline provider without having a function, tell me how "configuration segregation" can solve that. Spoilers, it can't.

[hadronized]

If people don’t really care about providing a better UX for end-user then yeah, why are you commenting on this issue?

I want to know how many people adopted your json config vs how many people are using lua for config, before you go saying my idea is just better and don't talk if you don't agree.

1. I haven’t worked on this in a while and haven’t reached a state where I would advertise for it more than saying I’m working on it.
2. I haven’t officially announced it as usable.

So I don’t get your point about poesie, especially since poesie is a plugin effort, which is not ideal to me as I would like to have that in neovim directly.

[mjlbach]

I want to know how many people adopted your json config vs how many people are using lua for config, before you go saying my idea is just better and don't talk if you don't agree.

Can we lower the temperature a bit? It's not fair to compare the built-in scripting language of neovim to a one-off plugin.

This issue isn't principally about how to configure neovim, but about providing official resources for plugin structure/development, and maybe having some plaintext format that describes plugin.

[hadronized]

but also allow them to in case they want to.

Experience has taught me that if you allow someone to do something, they will abuse it. So no, I hard disagree on this. You can implement super complex and extensible plugins without pushing a Turing-complete language for configuration.

[famiu]

Experience has taught me that if you allow someone to do something, they will abuse it. So no, I hard disagree on this. You can implement super complex and extensible plugins without pushing a Turing-complete language for configuration.

Again, you still haven't told me how "configuration segregation" can allow someone to mimic a statusline provider in one of the configurable statuslines (eg: galaxyline.nvim or feline.nvim0

[bfredl]

Experience has taught me that if you allow someone to do something, they will abuse it. [...] You can implement super complex and extensible plugins without pushing a Turing-complete language for configuration.

Sure but that cuts both ways. I don't think it is better by users embedding lua functions as string in a json config ( i e for their statusbar modules), which is something that will happen (according to the same principle), rather than just using lua directly to configure the plugin..

[hadronized]

Experience has taught me that if you allow someone to do something, they will abuse it. So no, I hard disagree on this. You can implement super complex and extensible plugins without pushing a Turing-complete language for configuration.

Again, you still haven't told me how "configuration segregation" can allow someone to mimic a statusline provider in one of the configurable statuslines (eg: galaxyline.nvim or feline.nvim0

You’d use string placeholders to represent various bits of info and let the user build the statusline by providing a string with the content. Or simply do it the way starship.rs does its prompt thing (it’s all toml). If you want to add a new feature, then you want to add code, not configuration.

But this whole conversation just confirms what I’ve been thinking about what people want from Neovim. It’s not « bad » to me, but it’s not the direction I expect a modern editor to go to. So I’ll probably shut up, I’m minority anyway regarding that topic, I always have been. That discussion started more than a year ago and even then I was basically the only one.

Good luck.

[shadmansaleh]

I want to know how many people adopted your json config vs how many people are using lua for config, before you go saying my idea is just better and don't talk if you don't agree.

Sorry that was harsh of me. I just wanted to say the json idea was out their but didn't see anyone else pursue it.

This issue isn't principally about how to configure neovim, but about providing official resources for plugin structure/development, and maybe having some plaintext format that describes plugin.

I can agree on having a json file storing metadata about plugin(name, author, url, version ...) but setting keymaps through json feels limiting.

if you allow someone to do something, they will abuse it. So no, I hard disagree on this.

It can be argued configurability and and extendibility in vim/neovim can abused by user . But I'm sure many people love vim/neovim because of it's extendibility . If user is abusing the power bestowed upon them that's their issue imo . That doesn't mean we should strip the ability from everyone .

[mjlbach]

I'm closing this as I think it's drifted off-topic, and I'm not interested in driving this forward anymore. If people want to continue this discussion on matrix or discourse that's fine.

[famiu]

You’d use string placeholders to represent various bits of info and let the user build the statusline by providing a string with the content. Or simply do it the way starship.rs does its prompt thing (it’s all toml). If you want to add a new feature, then you want to add code, not configuration.

But this whole conversation just confirms what I’ve been thinking about what people want from Neovim. It’s not « bad » to me, but it’s not the direction I expect a modern editor to go to. So I’ll probably shut up, I’m minority anyway regarding that topic, I always have been. That discussion started more than a year ago and even then I was basically the only one.

Good luck.

First off, apologies if I came off as harsh. The question about statusline providers was a genuine question and not an attempt to make you retract your comment or anything of that sort. I get your point about "modern editors" and honestly I agree that by default any plugin shouldn't require a user to put a function as configuration, but I still think it should be an option. I agree that every option gives scope for the user to abuse it, but at the same time I think that's just a minority and those who use it can make good use of it.

Either way, none of this probably matters anymore since this issue got closed anyway, which is a bummer since I was really excited for this.