Re-design configuration schema (or approach)

[hrsh7th]

I've no satisfied the current configuration schema... help or opinions are wanted.

[rafamadriz]

Not sure if I should ask this here or create a new issue. I've been following this since the beginning and something that I still don't understand the reason behind, is why having the sources as different plugins instead of them being included in the main plugin as it was in nvim-compe.

Isn't this a completion plugin ? shouldn't be some of those sources be included by default ?

Not necessarily include all of the sources that nvim-compe has by default but at least something basic like buffer and path source of completion to have a more "out the box" experience. I can understand the lsp, snippets and others sources being included as extra plugins. But not having things like buffer and path which is something really basic that I feel like any completion plugin should have out the box, just seems strange to me.

Maybe there's a good reason to go with this approach, so let me know.

But anyway that's just my opinion, I think that some sources should be included by default without having to install any extra plugin.

[elianiva]

why having the sources as different plugins instead of them being included in the main plugin as it was in nvim-compe.

it's harder to maintain iirc, there was a discussion about this in nvim-compe issue sorry, I can't remember which one exactly (and github throws a 500 error whenever I try to check old issues/PR), but I remember I suggested to put them in a different repo but there was no maintainer back then so a lot of them stayed in compe repo

I can understand the lsp, snippets and others sources being included as extra plugins. But not having things like buffer and path which is something really basic that I feel like any completion plugin should have out the box, just seems strange to me.

I'm sure people will have different opinion on which one should be included by default. Some will say LSP should be the default since nvim-cmp supports (almost?) all LSP completion features. The source installation is just a single line (probably list them in the Wiki or something, similar to how Telescope list its extensions, people can always add their source to the wiki themself)

but anyway(!), that's also just my opinion :laughing:

[Shougo]

If completion plugin include sources, the issues will be hard to maintain. Because the issues includes many source problems like current nvim-cmp issues. And the sources may add overhead to your Vim.

Not necessarily include all of the sources that nvim-compe has by default but at least something basic like buffer and path source of completion to have a more "out the box" experience.

Yes. It can. But what is the basic? Some people say "lsp!" and some people say "I don't like buffer source!". Oh, bikeshedding arguments. I think it is the best that none of sources are included.

[rafamadriz]

If completion plugin include sources, the issues will be hard to maintain. Because the issues includes many source problems like current nvim-cmp issues.

got it, that completely makes sense.

Yes. It can. But what is the basic? Some people say "lsp!" and some people say "I don't like buffer source!". Oh, bikeshedding arguments.

yes that can be problematic on what can be considered as "basic", people have their own preferences.

[Jesse-Bakker]

Looking at the example configuration, I have two notes:

1. I do not think a plugin setup should concern itself with setting mappings. Neovim already has good facilities to create mappings and having a different approach in a plugin smells like feature creep.
2. In the example, sources are defined using their "name", e.g.: sources = { { name = 'buffer' } }. It is not clear to me how these are resolved, but it might be nice to just use the source item as defined in the "Source creation" part of the README instead.

[akinsho]

I do not think a plugin setup should concern itself with setting mappings. Neovim already has good facilities to create mappings and having a different approach in a plugin smells like feature creep.

I don't think this is feature creep there are quite a lot of examples of plugins doing this gitsigns, nvim-tree, diffview.nvim, neoscroll, orgmode.nvim, fugitive tbh I'd say optionally applying mappings is a very common pattern especially since currently you still have to map to strings unless you've developed something custom in your init.lua whereas this seems to take lua functions directly which is much easier to use for the majority of people who don't have these workarounds in place already.

[hrsh7th]

IMO, I don't like the plugin apply mappings by itself. I think the plugin should provide <Plug> mapping instead.

But I decided to provide setup { mapping = { ... } } API in nvim-cmp.

The reason is that I received a lot of issues with this.

https://github.com/hrsh7th/nvim-compe/issues/103 https://github.com/hrsh7th/nvim-compe/issues/74 https://github.com/hrsh7th/nvim-compe/issues/121 https://github.com/hrsh7th/nvim-compe/issues/171 https://github.com/hrsh7th/nvim-compe/issues/361 https://github.com/hrsh7th/nvim-compe/issues/425

[numToStr]

In regards to maintenance, Why not make a Github organization under the name of nvim-cmp and develop all the plugins and sources there? Just like nvim-lua.

[hrsh7th]

done for now. I can create nvim-cmp organization but I hadn't ever do it.

If you have strong opinion about it, please create separated issue.