feat(luasnip): add virtual text to snippets and add lunarvim snippets

[danielo515]

Description

This adds virtual text to the current insertion point of lua-snip. It also creates a new entry in the lua-snip dictionary in case anyone wants to configure it through lunar vim. Take a look at the below screenshot to see how it looks like in case of a regular snippet

below screenshot show how it looks when you are on a choice node within a snippet

How Has This Been Tested?

• Execute any luasnip command with insertion points
• See how you get virtual text hints about where the current insertion point is

[kylo252]

please create a new config file for luasnip, see #2546 (comment)

[danielo515]

@kylo252 I added what you have requested and implemented one of the ideas mentioned on that PR (adding optional lunarvim snippets)

[kylo252]

I'm not too sure about the structure yet, but looks like a really good refactor!

[kylo252]

Suggested change

	lunarvim = true,
	user = {
	paths = {
	utils.join_paths(get_config_dir(), "snippets")
	}
	},

[danielo515]

My intention was to add lunarvim specific snippets, hence the name. It is a boolean to easily disable it in case you don't want them, it was not meant to be extended.
Allowing for arbitrary user paths is not trivial because luasnip needs the correct paths when you call the loader methods, you can't just call it and let it figure out which paths are for what things.

[kylo252]

okay, now I see what you mean! the problem is that we should still expose the snippets path (probably both lua and json as per #2962 (comment))

[kylo252]

Suggested change

	paths[#paths + 1] = utils.join_paths(get_runtime_dir(), "site", "pack", "packer", "start", "friendly-snippets")
	vim.list_extend(paths, lvim.builtin.luasnip.sources.friendly_snippets.paths)

[kylo252]

Suggested change

	local user_snippets = utils.join_paths(get_config_dir(), "snippets")
	if utils.is_directory(user_snippets) then
	paths[#paths + 1] = user_snippets
	end
	for _, dir in ipairs(lvim.builtin.luasnip.sources.user.paths) do
	if utils.is_directory(dir) then
	vim.list_extend(paths, dir)
	end
	end

[kylo252]

• I'm not sure this will be clear enough, we probably need to make a distinction between lua and json snippets.
• is it possible to lock a snippet to a folder/file? for lvim specific

[danielo515]

• I'm not sure this will be clear enough, we probably need to make a distinction between lua and json snippets.

What do you mean by it not being clear enough? To who it needs to be clear? This is not user facing. I think any dev working with this part of the app will understand this is a call to one of the LuaSnip APIs to add the snippets referenced in the require.

• is it possible to lock a snippet to a folder/file? for lvim specific

I'm not sure if I understand correctly what you mean. But if you mean to only add lunar-vim snippets when you enter/open lunar-vim folders I think we can add an autocomand on buf-enter that checks the path and adds the snippets if it matches one of the lvim runtime paths or config paths or something like that, but it may be tricky for users that do not use the regular folder path (just like me). I thought about that, and I came to the conclusion that it is better to just let the user disable them if they find them not useful.

[kylo252]

What do you mean by it not being clear enough?

judging by how you're using it, luasnip.sources.lunarvim is responsible for loading lua snippets as well as json-style ones. I'm not sure what an easy way would be to differentiate the two cases.

but it may be tricky for users that do not use the regular folder path

That should always be covered with $LUNARVIM_CONFIG_DIR, I don't see how it wouldn't be. Although, I was hoping for a native option in luasnip, as anything else would be more effort than warranted.

[danielo515]

judging by how you're using it, luasnip.sources.lunarvim is responsible for loading lua snippets as well as json-style ones. I'm not sure what an easy way would be to differentiate the two cases.

Sorry, I have been reading the luasnips docs recently and I assume a familiarity that probably not everybody has. Luasnip has a bunch of mechanisms to load snippets, and this is just one of them.
There are the snippet loaders, which are the most common and convenient way to load snippets into luansip.
You can also parametrize those loaders with additional paths for luasnip to load. This is what we do to load the snippets from the friendly snippets folder. If you don't provide any path, the loader will automatically search in a bunch of places within the runtimepath.
Lastly, there is the programmatic API (which is internally used by the loader) that allows you to pass one or two tables containing snippets. This last method is what I am using here. The reason is because it is more convenient this way. We don't have to mess with concatenating/generating paths that may vary drastically depending on the user environment. Since they are supposed to be built into lunarvim we can just require them and add them in case the user wants to enable them via config.
This has nothing to do with the users adding their own snippets, they can always call the different methods (the API, the different loaders) with the parameters they want to additionally load their snippets from whenever they want. I don't see a reason to abstract that away.

Hope this makes sense.

[danielo515]

By the way, I recently added docs to LunarVim about how to load snippets from Lua. That is still valid: https://www.lunarvim.org/configuration/08-custom-snippets.html#lua-version

[rebuilt]

I switched over to this as my main branch today. I'll test it out.

[rebuilt]

Seems to do what it says on the tin.

[danielo515]

Can we merge this and iterate over it in another PR? I do't have time to test the suggested changes, and from just reading the code I'm not sure they will work.

[danielo515]

So, this has been already approved. Can we merge it?

[LostNeophyte]

So, this has been already approved. Can we merge it?

The merging is not up to me, but please change the base branch from rolling to master, I won't attempt to do it this time xD

outdated

[kylo252]

Can we merge this and iterate over it in another PR? I do't have time to test the suggested changes

thanks for the effort, I've cherry-picked your commits into #3525