allow wild menu to be above statusline

[max397574]

would it be possible to allow the wildmenu to be above the statusline?
(open it on a row 1 smaller?)

[Shougo]

Why the feature is needed?

[wookayin]

Maybe because the floating window hides the statusline and the OP wants to see the statusline (filename, etc.)

[tzachar]

you can try this patch:

diff --git a/lua/cmp/view/wildmenu_entries_view.lua b/lua/cmp/view/wildmenu_entries_view.lua
index 3419164..ce3eeda 100644
--- a/lua/cmp/view/wildmenu_entries_view.lua
+++ b/lua/cmp/view/wildmenu_entries_view.lua
@@ -127,7 +127,7 @@ wildmenu_entries_view.open = function(self, offset, entries)
   self.entries_win:open({
     relative = 'editor',
     style = 'minimal',
-    row = vim.o.lines - 2,
+    row = vim.o.lines - 3,
     col = 0,
     width = vim.o.columns,
     height = 1,

If this works for you, you can create a pull requests which makes the row offset configurable.

[max397574]

works for me
I'll open a pr soon

[hrsh7th]

I think the nvim-cmp should not have any view related features except the default float-win menu.

But for now, I can accept PR.

[max397574]

Perhaps you could add a table with which you deep_extend the window options

[jdrouhard]

Quick note about this:

if cmdheight is set to 2 (many people do this so error messages don't require a "press any key" interaction to keep working), then the wildmenu window actually covers the command line and you can't even see what you are typing.

@hrsh7th - Would it make sense to calculate the row to display the wildmenu on based on cmdheight instead of a hard coded value?

[max397574]

and make it configurable
sth like:
pos=vim.opt.lines-(user_conf or cmdheight or 2)

[hrsh7th]

Would it make sense to calculate the row to display the wildmenu on based on cmdheight instead of a hard coded value?

It's make sense.

To be honest, I want to remove the wild menu view.
Currently, nvim-cmp has no mechanism for pluggable view-related functionality so I keep it.

[max397574]

why do you want to remove it?

[hrsh7th]

That's because I think it's basically an anti-pattern to absorb the differences in people's preferences in one implementation in one repository.

We could have just a single implementation if you're happy with a few settings, such as prettier, but in reality various requests have been submitted regarding the appearance of nvim-cmp.

[tzachar]

Personally, I disagree that it's an anti pattern. My reasoning is that the average user cannot, or will not, take the extra effort of installing plugins for his plugins. It becomes much too complicated and highly fragmented. There is also the problem of discovery. There is no central way of informing users of all the various different plugins or sources available for cmp.

…

On Mon, 2 May 2022, 19:31 hrsh7th, ***@***.***> wrote: That's because I think it's basically an anti-pattern to absorb the differences in people's preferences in one implementation in one repository. We could have just a single implementation if you're happy with a few settings, such as prettier, but in reality various requests have been submitted regarding the appearance of nvim-cmp. — Reply to this email directly, view it on GitHub <#908 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFXXCZAXEOTUGZISVDPGNDVH77PTANCNFSM5TSO4POQ> . You are receiving this because you commented.Message ID: ***@***.***>

[hrsh7th]

I don't think nvim-cmp does not have any built-in sources is make good ecosystem and it does not make unnecessary effort to the user.

For example, you did make cmo-fuzzy-buffer. it's interesting and might be useful for some users. This is due to current design.

[tzachar]

My point is that we need to have a central place where users can _find_ all of these plugins. And we need to better document their use. The flip side of building cmp to be highly configurable is that users will encounter more issues down the road, where external plugins misbehave. This will increase the pressure on cmp maintainers (which should probanly increase in numbers anyway).

…

On Tue, 3 May 2022, 9:02 hrsh7th, ***@***.***> wrote: I don't think nvim-cmp does not have any built-in sources is make good ecosystem and it does not make unnecessary effort to the user. For example, you did make cmo-fuzzy-buffer. it's interesting and might be useful for some users. This is due to current design. — Reply to this email directly, view it on GitHub <#908 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFXXC66OG5RNFPJTNR36RLVIC6RDANCNFSM5TSO4POQ> . You are receiving this because you commented.Message ID: ***@***.***>

[hrsh7th]

I think distributed design is cut off the maintein cost.
For example, I don't maintein cmp-ultisnips and cmp-luasnip. It's supporting by other mainteners.

I can focus core functionality and stability.

[tzachar]

As you say, you are a single person. You can only do so much. A different approach is to add other maintainers to help alleviate the load.

If you look at other nvim plugins, they are mostly single repo plugins, without having plugins of themselves. The only plugin which comes to mind which does have its own plugins is telescope, and you can see the complexity this adds to setting it up.

[Shougo]

My point is that we need to have a central place where users can find all
of these plugins.

I think you can search plugins by https://github.com/topics/nvim-cmp.
I don't think the central repository is needed. And it seems off topic.

[tzachar]

Not sure its off topic; You are talking about changing the core of cmp to make it more customizable, refactoring all of the views (for example) into external plugins. What I am saying is that this will only exacerbate the current problem of cmp users, where it's quite difficult to know which plugins are available and what is the recommended way of using them.

[Shougo]

Not sure its off topic; You are talking about changing the core of cmp to make it more customizable, refactoring all of the views (for example) into external plugins. What I am saying is that this will only exacerbate the current problem of cmp users, where it's quite difficult to know which plugins are available and what is the recommended way of using them.

The sources are already splitted. I think the external view plugins system is nice.
ddu.vim already implements it(the view is splitted).

The flip side of building cmp to be highly configurable is that users will
encounter more issues down the road, where external plugins misbehave. This
will increase the pressure on cmp maintainers (which should probanly
increase in numbers anyway).

The one(central) plugin repository really solves the problem?
Have you read telescope.nvim issues?
In telescope.nvim issues, many external sources issues pollutes the issues.
I know nvim-cmp's configuration is complex. But it seems customization design trade off.

[tzachar]

The sources are already splitted. I think the external view plugins system is nice. ddu.vim already implements it(the view is splitted).

Nice should not be driving the decision here.

The flip side of building cmp to be highly configurable is that users will
encounter more issues down the road, where external plugins misbehave. This
will increase the pressure on cmp maintainers (which should probanly
increase in numbers anyway).

The one(central) plugin repository really solves the problem? Have you read telescope.nvim issues? In telescope.nvim issues, many external sources issues pollutes the issues. I know nvim-cmp's configuration is complex. But it seems customization design trade off.
This above is exactly my point. The external plugin issues will pollut cmp. You will find yourself with hundreds of issues not related to core cmp, but to some esoteric external plugin. Placing the burden of decoupling cmp-core and any cmp-plugin on users whenever they have an issue will only hurt adoption of cmp.

I think that cmp is a really amazing piece of code. Extensibility is also a key part of it. But I think success is starting to show its downsides, where you have a large user base and issues start to creep.

I would think about this entire issue from a different perspective. We should ask what is the long term plan for cmp. It started out as a personal project for you @hrsh7th, but I think it is much more than that now.

[max397574]

tbh I don't care if you move the different view to external repositories
just don't remove them

[Shougo]

I think that cmp is a really amazing piece of code. Extensibility is also a key part of it. But I think success is starting to show its downsides, where you have a large user base and issues start to creep.

I know the user base is very huge. I have read key mappings decision(the default key mappings is removed) issues.
I think the decision is right. But on the user side, it is not right...

I would think about this entire issue from a different perspective. We should ask what is the long term plan for cmp. It started out as a personal project for you @hrsh7th, but I think it is much more than that now.

Current nvim-cmp seems neovim standard auto completion framework.
It is not just hobby product. It may be a tragedy.

[hrsh7th]

As the developer of telescope.nvim mentioned, I think it's a bad idea to implement features in this repository that I'm not using. They are not maintained and bug reports are difficult to deal with.

Also, if we focus on the "general user", I still think the wildmenu view is subject to deletion.

I want nvim-cmp to be extensible enough to have a wildmenu view.
To do this, we need to provide the appropriate plugin system or extension point to userland.

[hrsh7th]

I can understand the user expectation that I want to enable my favorite feature via one line config.
But it's the endless way. If we choose this approach, we have to introduce thousand configuration options.

[max397574]

imo your goal shouldn't be to allow users to enable their favorite features via one line config.
But you should allow all the favorite features to be enabled somehow by perhaps exposing window options or something similar (like e.g. telescope pickers do since we're talking about that)

For the wildmenu I don't care if you move it to a different repository but it something really useful and you should keep it somewhere.

[tzachar]

For the wildmenu I don't care if you move it to a different repository but it something really useful and you should keep it somewhere.

As the original author of the PR, it's nice to hear :)

@hrsh7th, it's your project, you should decide on how to move forward. I would be happy either way.

[max397574]

another thing kinda related to this
you should also allow the normal menu to be moved because: