Suggested way to create Rust Analyzer style postfix snippets

[zdcthomas]

Hey! Love the plugin, it's so powerful, and feels awesome!

I'm wondering if there's a straightforward way to create Rust Analyzer style postfix snippets? I know I could get the cursor position and get the word before the . before the cursor, but before I dug too much into that, I thought I'd see if there was an easier way.
If not, no problem!

Thanks for the help!

[L3MON4D3]

Hey! Love the plugin, it's so powerful, and feels awesome!

Nice, that's great to hear :)

regTrig should work here:

ls.setup_snip_env()

-- match multiple %w before a `.` and store them in the first capture-group.
ls.add_snippets("all", {s({trig="(%w+)%.parens", regTrig=true, wordTrig=false}, {
	f(function(_, parent)
		return "("..parent.snippet.captures[1]..")"
	end),
	l("("..l.CAPTURE1..")", {})
})}, {key = "testsnippetshehe"})

In general the captures can be accessed as snippet.captures[capture_group], for simple string-manipulations (like adding parenthesis above) you can just use lambda from luasnip.extras, makes it all a bit more readable.

Also, make sure to set wordTrig, otherwise luasnip will, when matching triggers, only consider text from the cursor back to the ., which is obviously problematic with postfix-snippets :D

[zdcthomas]

Ooo that sounds perfect! I gave it a try and I'm running into a few issues.
I copied your snippet example, but when I expand on foo.parens, it expands to foo.%w+%.parens with %w+ selected for replacement.

my config setup looks like

ls.config.set_config({
	updateevents = "TextChanged,TextChangedI",
	delete_check_events = "TextChanged,InsertEnter",
	region_check_events = "TextChanged",
	enable_autosnippets = false,
	store_selection_keys = "<Tab>",
	ext_opts = {
		[types.choiceNode] = {
			active = {
				virt_text = { { "●", "Boolean" } },
			},
		},
		[types.insertNode] = {
			active = {
				virt_text = { { "●", "Special" } },
			},
		},
	},
})

My guess is that I'm missing something in the config, but I can't quite find it.
Sorry! really appreciate the help!

[zdcthomas]

I'm using nvim cmp if that makes any difference

[zdcthomas]

ok, so I figured something out. If i create a new mapping just for expanding snippets, like

vim.keymap.set({ "i", "s" }, "<c-t>", function()
	if ls.expand_or_jumpable() then
		ls.expand_or_jump()
	end
end)

then that works perfectly.
However, if I select the snippet from the cmp menu, it works how I described above.

[zdcthomas]

Ah ok, I figured it out I think. The snippet that shows up in cmp's menu is somehow different from the one that is expanded when I use that mapping. I'm guessing this might be an issue better opened on cmp luasnip right?

[L3MON4D3]

I'll have to start assuming cmp is used, it severly limits the number of hacky workarounds one could do 😅

The "problem" (only in this case) with cmp_luasnip is that it doesn't have a trigger to match against, it only knows which snippet should be expanded (because it's just picked from some list).
For normal snippets (not regTrig) this doesn't really make a difference, but when parts of the trigger are used (and necessary!) in the snippet (capture-groups, for instance) expanding it via cmp_luasnip could lead to some error during expansion (in this case the capture group would be nil, which obviously cannot happen if the snippet was expanded via trigger).
To work around this limitation, cmp_luasnip, when regTrig is set, expands a snippet which corresponds to the pattern used as trigger, so one can fill in the missing capture-groups.

This means that for compatibility with cmp, this problem should be solved properly, so you'd have to store the text before the . in some variable and remove it, just before expanding:

ls.setup_snip_env()

local postfix_opts = {
	callbacks = {
		[-1] = {
			[events.pre_expand] = function(snippet, event_args)
				local pos = event_args.expand_pos
				-- [1]: returns table, gets text end-exclusive.
				local line_to_cursor = vim.api.nvim_buf_get_text(0, pos[1], 0, pos[1], pos[2], {})[1]
				local pre_dot = line_to_cursor:match("%w*$")
				-- clear pre_dot-text.
				vim.api.nvim_buf_set_text(0, pos[1], pos[2]-#pre_dot, pos[1], pos[2], {""})
				snippet.pre_dot = pre_dot
			end
		}
	}
}

ls.add_snippets("all", {
	s({trig = ".parens", wordTrig=false}, {
		f(function(_, parent)
			return "(" .. parent.pre_dot .. ")"
		end, {})
	}, postfix_opts)
}, {
	key = "asdfadsfasdfasdfsd"
})

The nice thing here is that it's pretty straightforward to turn a snippet into a postfix, just pass postfix_opts to s and you can access snippet.pre_dot in function/dynamicNode (not from lambda though, to do that you'd have to pass the pre_dot-text somewhere lambda can access it, eg. snippet.captures[1])

[zdcthomas]

That works great! thanks!

This is super interesting. So since it's just selected from a list, it doesn't have the necessary expand params that it would if it was expanded normally?
Would it be super difficult to generate those expand params before the snip expand in cmp luasnip? I understand that faking it out could lead to trying to expand a snippet that doesn't actually match the trigger, but is that the only issue there?

Also, thanks so much for taking all this time! I really appreciate it, and if I understand the problem better, I'd love to see if there's a PR somewhere I can make to help out on this!

[L3MON4D3]

That works great! thanks!

Nice, you're welcome!

This is super interesting. So since it's just selected from a list, it doesn't have the necessary expand params that it would if it was expanded normally? Would it be super difficult to generate those expand params before the snip expand in cmp luasnip? I understand that faking it out could lead to trying to expand a snippet that doesn't actually match the trigger, but is that the only issue there?

There are two problems:

• generate a string that doesn't cause any errors: for example, when the trigger is something like "asdf(%d)", the snippet can assume that the first capture group is surely a number, and just tonumber it. This works fine during regular expansion, but we'd have to take extra care here when generating the expand params.
• generate a string that actually makes sense: in the best case, the generated expand params should fit the context of the snippet, but just the trigger is generally not enough information I think.
  For example, the trigger could be (%d%d).(%d%d).(%d%d%d%d), and in the best case it'd be recognized as a date, but that seems impossible to do generally.

I think the current solution (expand a snippet for the trigger-pattern) is pretty good in most cases (one could enter the date a bit more comfortably that way) but it doesn't make any sense in others like the postfix.

Another option might be to allow for more customisation, for example via a per-snippet cmp_expand-callback.

Also, thanks so much for taking all this time!

Oh I'll gladly help with more involved snippets when they could be of general interest, which applies to postfix-triggered ones I think :D

I really appreciate it, and if I understand the problem better, I'd love to see if there's a PR somewhere I can make to help out on this!

The additional callback could be interesting, but I'm not sure if there are snippets that really require it, or if we should just be more clear about expanding some intermediary snippet instead of the selected one.

[zdcthomas]

Ok, I've been toying around with the cmp integration and I have a way that this can work, albeit not amazingly.

The change is that regTrig snippets are only added to the menu if they actually match the line, and then because of that, they can safely be passed the expand_params when they do. The only downside is that the snippet won't display unless it's fully matched, though.

[zdcthomas]

So far, what I hacked together over in the cmp integration isn't half as good a user experience as the pre_expand callback solution you provided. I was trying to figure out if it might be helpful for me to put together a special postfix type of snippet that would do the same thing, and open up a Pr. What do you think?

[L3MON4D3]

Ouh please do!
This would be something nice for luasnip.extras(.postfix?) I think :D

[zdcthomas]

Implemented in #463