snippet support for mini.completion

[olekspickle]

Contributing guidelines

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md

Module(s)

completion

Description

I already created the issue #882 about having $0 after completion.
I also then created an issue on LSP side where they explained that this is what is coming to Neovim 0.10 natively.

But mini.completion isn't supporting snippets, correct? if so, would you be open to support it or accept PR? currently I have no idea about volume of work to be done for it, but sound interesting and might help me get familiar with all this Lua madness.

[echasnovski]

Thanks for the suggestion!

Yes, this is planned after the release of 'mini.snippets'. As 0.10 is released, this will now be possible to start working on. Yet, no concrete plans.

I appreciated the suggestion, but 'mini.completion' is one of the messiest module in 'mini.nvim' and I'll tackle it myself.

Let's have this issue open so as an extra measure to not forget about it.

[flexagoon]

@echasnovski can the 0.11 LSP completion side effects api be used for this?

[echasnovski]

@echasnovski can the 0.11 LSP completion side effects api be used for this?

I am afraid I am not really sure what you're referring to. Could you link to it, please?

But if it is only 0.11, then it probably won't be used as I'd like 'mini.nvim' (and snippet support in 'mini.completion') to support as many versions as possible. Right now it should be possible to support 0.10+ but maybe after 'mini.snippets' this can get better.

[flexagoon]

Oh, turns out this wasn't actually added in 0.11

I was referring to the vim.lsp.util.apply_text_edits function. It seems like unless you need to have custom snippet support then using it together with the new snippets API should provide a very simple way to expand most existing LSP completions?

[echasnovski]

I was referring to the vim.lsp.util.apply_text_edits function. It seems like unless you need to have custom snippet support then using it together with the new snippets API should provide a very simple way to expand most existing LSP completions?

I think just using vim.snippet should be enough. It is just that resolving this issue is intentionally postponed after 'mini.snippets' is a thing. So that I'd have more knowledge about snippets and can be sure that I've tried to support as many previous Neovim versions as possible.

[flexagoon]

@echasnovski another thing that I thought:

A lot of the functionality of mini.completion is duplicating the functionality added in core with vim.lsp.completion. The main difference is that mini.completion has proper auto complete, while built-in is only activated on trigger chars.

So perhaps, when 0.11 is released, it would make sense to refactor that plugin to remove all of the custom popup menu item building and rely on vim.lsp.completion.trigger() instead? This would simplify the code, fit the plugin's goal of using as much native stuff as possible, and, as an additional benefit, bring support for snippets and stuff for free.

[echasnovski]

A lot of the functionality of mini.completion is duplicating the functionality added in core with vim.lsp.completion. The main difference is that mini.completion has proper auto complete, while built-in is only activated on trigger chars.

Purely due to how time works, I'd like to think that it is vim.lsp.completion which is duplicating 'mini.completion' functionality :) Although it used 'mfussenegger/nvim-lsp-compl' as a reference :) Or a more neutral "they share similar functionality" is even better.

So perhaps, when 0.11 is released, it would make sense to refactor that plugin to remove all of the custom popup menu item building and rely on vim.lsp.completion.trigger() instead? This would simplify the code, fit the plugin's goal of using as much native stuff as possible, and, as an additional benefit, bring support for snippets and stuff for free.

Although motivation is sound, there are several crucial problems:

• 'mini.nvim' does not only support latest stable, but also two (minor) versions prior. So it will be not until the release of Neovim 0.13 when 'mini.completion' can be rewritten to use vim.lsp.completion.
• One big thing that I'd taken into account was that completion candidates persist across deleting characters. I.e. after completion candidates are shown, pressing <BS> should still show them with possibly bigger set of matched candidates. This is not the case with vim.lsp.completion (as far as my experiments and looking at its code showed) and I am not sure if it will be. Supporting this use case is one of the main reasons why 'mini.completion' uses 'omnifunc' and 'completefunc' approach instead of relying on vim.fn.complete() (which is what vim.lsp.completion currently uses).

[flexagoon]

Purely due to how time works, I'd like to think that it is vim.lsp.completion which is duplicating 'mini.completion' functionality :) Although it used 'mfussenegger/nvim-lsp-compl' as a reference :) Or a more neutral "they share similar functionality" is even better.

I didn't mean that in the sense that you stole the functionality or anything like that :) I purely meant that by installing mini.completion you're now introducing extra code logic duplication. In the same sense I'd say that mini.comment is duplicating the functionality of built-in commenting, despite the fact that the built-in feature was implemented by you and based on mini.comment.

One big thing that I'd taken into account was that completion candidates persist across deleting characters

I see, that makes sense. Perhaps when 0.11 is released you should add this note to the "difference from alternatives" section in the mini.completion docs?

---

The reason I asked is that I was playing around with native LSP completion and realized that the only things it lacks for me are pretty colors and proper autocompletion. With the ability to set pretty colors now being implemented (neovim/neovim#30060), I was wondering if there could be a plugin that simply adds autocomplete logic on top of native completion.

But I guess just adding an autocmd with a few checks and a timer is enough for basic autocomplete, and it sounds simple enough that I could just do it in my nvim config without a plugin.

[echasnovski]

... purely meant that by installing mini.completion you're now introducing extra code logic duplication.

The overlap is not that big, I'd say, and it was already present from 'mini.completion' start (as its core initially was similar to vim.lsp.omnifunc). The "autotrigger" parts are quite different.

In the same sense I'd say that mini.comment is duplicating the functionality of built-in commenting, despite the fact that the built-in feature was implemented by you and based on mini.comment.

Yeah, unfortunately, no good way to reuse built-in commenting because there is no exported Lua functions by design (otherwise no merge would happen). 'mini.comment' still offers more on top, though.

The reason I asked is that I was playing around with native LSP completion and realized that the only things it lacks for me are pretty colors and proper autocompletion.

Fallback to built-in "usual" completion is a big part of 'mini.completion' and was one of the goals of even creating it. Because not every buffer has LSP attached to it yet autocompletion is still useful.

With the ability to set pretty colors now being implemented (neovim/neovim#30060), I was wondering if there could be a plugin that simply adds autocomplete logic on top of native completion.

This doesn't look like a relevant PR. As far as I know, there is no way of setting highlight group in popup menu yet. This functionality needs to go through Vim and vim/vim#15561 seems to be the first step.

[flexagoon]

This doesn't look like a relevant PR. As far as I know, there is no way of setting highlight group in popup menu yet.

Completion items have a hl_group attribute, and this PR allows to set it. The vim PR you linked references the issue I opened yesterday in nvim, and it introduces the option to set a hlgroup just for the kind text, but it's already possible to set a hlgroup for the entire completion item

[echasnovski]

Completion items have a hl_group attribute, and this PR allows to set it. The vim PR you linked references the issue I opened yesterday in nvim, and it introduces the option to set a hlgroup just for the kind text, but it's already possible to set a hlgroup for the entire completion item

Oh, indeed, my bad. It was added around a month ago, didn't catch that. This is a good time to incorporate 'mini.icons' into 'mini.completion' then. Thanks for the info!

[echasnovski]

@flexagoon, 'mini.completion' now by default highlights LSP kind (with kind_hlgroup) on Neovim>=0.11 if 'mini.icons' is enabled. It uses highlight groups from its "lsp" category. This requires enabling 'mini.icons', but I think it is a good alternative to possibly allowing customizing that highlighting in MiniCompletion.config. And I also don't really like the idea of something like convert from the vim.lsp.completion.BufferOpts as there is already a MiniCompletion.config.lsp_completion.process_items (which doesn't allow overriding kind_hlgroup, but I think it can be added if there is a demand).

All in all, thanks for the tip about the new hl_group and kind_hlgroup fields in completion items!

[echasnovski]

And I also don't really like the idea of something like convert from the vim.lsp.completion.BufferOpts as there is already a MiniCompletion.config.lsp_completion.process_items (which doesn't allow overriding kind_hlgroup, but I think it can be added if there is a demand).

After sleeping on it, allowing config.lsp_completion.process_items to set kind_hlgroup is the cleaner solution. The default 'mini.icons' one is shuffled to MiniCompletion.default_process_items() and still works as default (if 'mini.icons' is enabled). This should now be the part of main.

[GitMurf]

Just checking in to see if mini.snippets development is underway or any updates on roadmap for it :) thanks as usual!!

[echasnovski]

Yes, it is in development.

[GitMurf]

Yes, it is in development.

Awesome! Whenever you need early testers please let me know!