LuaSnip
LuaSnip copied to clipboard
Replace snippets with the same name
When loading snippets from friendly-snippets and your custom config there may be snippets which have the same name/trigger, both of which will show up in the completion menu (nvim-cmp).
It would be useful for an option to replace existing snippets with the same name to allow overriding some predefined snippets with your own, which is how vsnip handled it.
Any input is appreciated.
I want to just say "create a local copy of friendly-snippets and remove those snippets", but it's been brought up a few times now, I think we ought to implement something to support this.
There's priority
, which can be used match the trigger for custom-snippets before friendly-snippets
(friendly-snippets
loaded with prio 1000, custom snippets with 1001), but it won't hide the snippet in cmp.
Maybe we could add a setting which, when set, finds duplicate snippets and removes those with lower priority (or, more precisely, those that would not be expanded when triggering snippets manually). The setting should probably be global(instead of an argument to add_snippets) , otherwise any add_snippets-call without the setting set could introduce duplicates again. It should also be off by default, just because it's overhead that might be unwanted.
That sounds like a fantastic solution
Great, might be a while until this is added though :sweat_smile:
Have you started working on it yet or should I start looking at it and open a PR?
If so, I will add a setting called remove_duplicates = false
and make it remove them on add_snippets
Ah, no I have not so far
I'd welcome a PR for this, but my initial idea might be a bit flawed: we cannot tell, during add_snippets
, which snippet will ultimately be expanded, because filetypes can be reordered:
- add
if
-snippet forc
- add
if
-snippet forcpp
- via
ls.filetype_set
,c
andcpp
can be queried in either order, so we cannot tell which will be expanded during runtime.
remove_duplicates
would have to be filetype-local to prevent this problem.
Would it perhaps be a better idea to filter out duplicates once snippets are queried instead. That way, LSP one-off snippets like those from rust analyzer could also be set to either override yours or the other way around.
Mhmm, overriding snippets from lsp isn't possible from luasnip (at least not in the way you'd want to I think). We just get the snippet-body and can then refuse to expand it, but the snippets will still show up in nvim-cmp
, filtering those would have to happen in the source (cmp-nvim-lsp
) or in your config (via custom compare, or somthing like that, not certain it's possible).
To completely prevent duplicates in completion-engines, they would have to filter the list they show and remove duplicates entries.
I don't quite know yet how to best do this, the easiest way might even be generating the list of snippets for the current position in luasnip
, even though this isn't completely in scope for us, it prevents work that has to be implemented by all completion-sources for luasnip + we have to expose fewer internals, which could prevent breaking changes in the future.
Also, this would solve the problem I mentioned in my previous comment; now we do know the order of filetypes, so can do a perfect job at hiding duplicates.
Ok. Preventing duplicates in lsp snippets isn't such a big deal since they are different sources in nvim-cmp, so you can place luasnip above lsp. The lsp snippets aren't clashing too often with user defined snippets, like the rust-analyzer .arc
and .box
postfix snippets, compared to the 5 different struct
snippets I have.
I also would like to override friend-snippets with my own for certain snippets, (e.g. tests). I've tried overriding priority, but friendly-snippets still show up first. Am I doing something wrong with my config?
require("luasnip.loaders.from_vscode").lazy_load({
default_priority = 500,
override_priority = 500,
})
require("luasnip.loaders.from_vscode").lazy_load({
paths = vim.fn.stdpath"config" .. "/snippets",
default_priority = 2000,
override_priority = 2000,
})
"Show up first" in cmp? Yeah, nothing's implemented to prevent that as of now :/ The priority only affects ordering when manually expanding snippets. (though it would be possible to change the ordering by making use of cmps ranking (I think that's what it's called))
Ah ok, I got confused with how priority was used. That makes sense, I guess yeah then I'd say +1 for being able to 'replace' snippets.
How about provide a way to ignore or delete specific snippet in loader? Maybe the root problem is snippet packages (like friendly-snippets) can bring unwanted snippets.
I also think the abilitiy to override snippets would be super useful!
I'm currently using a fork of friendly-snippets like you mentioned @L3MON4D3, but it's not very practical having to keep up with the upstream, deal with merge conflicts, etc.
Also needing this :).
I'm interested in this use case as well, especially with cmp ordering being non-trivial to manipulate. Having duplicates not there to begin with would be a much better solution.