Regular expressions with end-of-line match

[weilbith]

Hey 👋🏾

I'm currently trying to improve my snippets as some of them expand automatically too often when it doesn't fit. Therefore I want to check if there is nothing in the line after the trigger. In theory this should be a simple end-of-line match in the trigger. But that doesn't work. Adding this makes the snippet never expand.

Here is an example. The trigger I was using so far was if[%( ]. So I simply added $ at the end of the trigger (see below). That doesn't work. To simplify the problem I also tried if $, but doesn't work neither.
Using ^ to match the start of the line works fine for me. No I'm unsure if this has something to do with how regular expressions are matched in the context of LuaSnip or if I don't understand a special case of the Lua expression syntax.

snippet(
  { trig = ' if[%( ]$', regTrig = true },
  if_node, -- ignore here to a simple example
}

Thanks for your help!

[L3MON4D3]

Hey!
Soo we currently handle pattern-triggers by

• appending a $ to the pattern
• matching that pattern against the line up to the cursor
  (here)

I guess we could match against the full line and iterate the matches, accept if one ends at the cursor.. but that would most likely be much slower than the current approach (but maybe worth looking into the performance-difference exactly).

Until then, I think a condition on the snippet might serve best, just check if the cursor is at the end of the line in there, and prevent expansion that way.

The condition-approach is also pretty nice since that can be handled better by cmp, via show_condition, which could be the same condition.

[weilbith]

Interesting. So I'll write such a condition. Should we close the issue then? 🤔

Talking about cmp: how can I list also auto snippets with cmp?

[weilbith]

To share my simple condition function to anyone who stumbles over this issue:

local function is_end_of_line(_, trigger)
  local line = vim.api.nvim_get_current_line()
  local match = line:match(trigger .. '$')
  return match ~= nil
end

snippet('trigger', node, { condition = is_end_of_line })

@L3MON4D3 there is this shared module that comes with LuaSnip and only contains a line_begin condition. Do you think we should add this function here too? Maybe in a better version if you don't like it.
Which brings me to another question: would it be possible to support a table of conditions which are anded? Like condition: { line_begin, line_end }, Now I have to write a wrapper function for every possible combination of conditions I would like to have.

And btw: what is more cheap/faster: a regex trigger like { trig = '^trigger', regTrig = true } or a { condition = line_begin }?

[L3MON4D3]

To share my simple condition function to anyone who stumbles over this issue:

local function is_end_of_line(_, trigger)
  local line = vim.api.nvim_get_current_line()
  local match = line:match(trigger .. '$')
  return match ~= nil
end

snippet('trigger', node, { condition = is_end_of_line })

@L3MON4D3 there is this shared module that comes with LuaSnip and only contains a line_begin condition. Do you think we should add this function here too? Maybe in a better version if you don't like it.

Oh yeah, good idea 👍
I think re-using the passed line_to_cursor and checking #line_to_cursor == #line would be a tad nicer, would you do a PR for that?

Which brings me to another question: would it be possible to support a table of conditions which are anded? Like condition: { line_begin, line_end }, Now I have to write a wrapper function for every possible combination of conditions I would like to have.

Right, that's useful, though it might be more flexible to do something like this:

local function and(...)
	local fns = {...}

	return function(...)
		for _, fn in ipairs(fns) do
			if not fn(...) then
				return false
			end
		end
		return true
	end
end

...
condition = and(line_begin, is_end_of_line)

Since we could also support other expressions, like or.
Exporting those as require("luasnip.extras.conditions").combinations.<and/or/xor??> seems like a good option, I'll think about it.

And btw: what is more cheap/faster: a regex trigger like { trig = '^trigger', regTrig = true } or a { condition = line_begin }?

I think plain trigger + condition should be faster, we have to call the condition, but can avoid the much more general (and therefore slower, I assume) pattern-matching.

[L3MON4D3]

Interesting. So I'll write such a condition. Should we close the issue then?

Let's close it when the new condition is merged, I'd say

Talking about cmp: how can I list also auto snippets with cmp?

Ah, not possible :/
There's a PR for that though, you could use that branch

[weilbith]

Oh yeah, good idea +1
I think re-using the passed line_to_cursor and checking #line_to_cursor == #line would be a tad nicer, would you do a PR for that?

Done. #597

Since we could also support other expressions, like or.
Exporting those as require("luasnip.extras.conditions").combinations.<and/or/xor??> seems like a good option, I'll think about it.

Would be cool to have it out of the box. For the moment I can put into my custom LuaSnip utilities. 👍🏾

think plain trigger + condition should be faster, we have to call the condition, but can avoid the much more general (and therefore slower, I assume) pattern-matching.

Is there a go way to measure this? 🤔
Maybe this is overengineering, but I'm a bit worried that my dozens of auto snippets could sum up to drop performance over time. So I start to think about what of a snippet impacts its performance. 🙈

Ah, not possible :/
There's a PR for that though, you could use that branch

You mean as a result of #513?

[L3MON4D3]

Done. #597

👌

Would be cool to have it out of the box. For the moment I can put into my custom LuaSnip utilities. 👍🏾

Yes, I agree! I'll look into how to best incorporate them

Is there a go way to measure this? thinking Maybe this is overengineering, but I'm a bit worried that my dozens of auto snippets could sum up to drop performance over time. So I start to think about what of a snippet impacts its performance. 🙈

Mhmmm, one thing you could do is start luajits profiler, and just use luasnip for a bit, and then take a look at how much time luasnip takes (Feel free to open an issue for this, too, might be interesting to take a look at performance in the wild, so to say :D)
(using jit-profiiler)
(although, maybe we need to manufacture a test for this, latency would be more interesting than total runtime..)
If snippets really do take a bit too long, I have some cool ideas to reduce time to look up snippets (sort/store by last trigger-character 😉 Won't apply to pattern-snippets though)

You mean as a result of #513?

Ah, no, unfortunately not 😅
That PR is in cmp_luasnip, here

[weilbith]

Talking about performance optimizations and sorting etc. It might be worth to investigate into common conditions. I could imagine that the majority of snippets picks from the same set of conditions. And most of them are snippet agnostic (like begin/end of line, being in a test file, ...). So a mechanism to run such a condition once and then filter all snippets that use this condition could be a great improvement. But keeping this open and extendible by the user (e.g. i could imagine your in-test-file might be different to mine) is a challenge.

Nevertheless, even though some ideas appear to be improvements for sure, it would still require performance measurement tests first. Else everything else is speculation and could be wrong. In worst case make the plugin internals complicated with worse performance.

Ah, no, unfortunately not 😅
That PR is in cmp_luasnip, here

Ah damn. Doesn't look too good.

[L3MON4D3]

Talking about performance optimizations and sorting etc. It might be worth to investigate into common conditions. I could imagine that the majority of snippets picks from the same set of conditions.

Ouh, yeah we could definitely memoize the results of conditions.
The code is here, if conditions are memoized (and therefore pretty quick) we could swap the trigger and the condition.

Not sure if switching is worth it though, checking the trigger is really fast, especially plain triggers.

Nevertheless, even though some ideas appear to be improvements for sure, it would still require performance measurement tests first. Else everything else is speculation and could be wrong. In worst case make the plugin internals complicated with worse performance.

👍

[atticus-sullivan]

Well when using fixed (and reused) functions, memoizing should be pretty simple. Make the function a table which (evaluates if necessary and then) returns on __call the stored true/false (not quite sure, but maybe its possible to even use the table itself as its metatable to reduce the amount of used tables).
This should work in each case the function (which secretly is a table) is used in no matter what context.

The weakness in this approach is, how are we're gonna invalidate the computed results that way?
I can only think this would be possible via some sort of hook which is being run at the end of match_snippet, in snippet_collection (I guess).
Two issues, first this hook would error if non-memoized functions/tables are being passed (so we'd need to check if the "thing" can/has to be invalidate). And second, we'd need to keep track of the evaluated (and possible memoized) stuff (which isn't that easy in snippet_collection as far as I read it).

Regarding logic operators, I consider functions like and() always a bit ugly regarding configs as it forces to use prefix operators (which isn't that readable). Maybe making the &, |, ~ operators (why not if we're already using metatables) would be nicer (thus having infix operators) to read.

[L3MON4D3]

Well when using fixed (and reused) functions, memoizing should be pretty simple. Make the function a table which (evaluates if necessary and then) returns on __call the stored true/false (not quite sure, but maybe its possible to even use the table itself as its metatable to reduce the amount of used tables).
This should work in each case the function (which secretly is a table) is used in no matter what context.

Nice, yes that would work. We already had a similar problem with #535, there we chose to use functions as keys for a table, instead of turning everything into tables with __call.
But __call is nice here because we wouldn't need to go through that table each time, it's probably the better choice for this 👍
Also, we could keep the match-code as-is

The weakness in this approach is, how are we're gonna invalidate the computed results that way?

Yeah, that's a bit hard.
We'd need to know what information the condition depends on, so that might have to specified somehow.
If it only depends on the values passed to it (or buffer-content and cursor-position), a combination of changedtick and the expand-position should work nicely.

And second, we'd need to keep track of the evaluated (and possible memoized) stuff

Couldn't the results be stored in the functions(tables) themselves?

Maybe making the &, |, ~ operators (why not if we're already using metatables) would be nicer (thus having infix operators) to read.

Ohhh did not know that was possible, would be pretty cool to overload them.

I think we might be able to do this entirely in extras.conditions (maybe also a different module), so

• one function to turn function into condition-object, with memoization and logical operators
  • maybe options for controlling memoization ("buffer", "changes", "cursor", "none", where each option would include the previous ones (so "cursor" would invalidate for a different buffer, different changedtick or different cursor-position))

[leiserfg]

The only pain point of using a meta with __call is that it's a bit slower than raw function calls, but I don't know if that will be noticeable in that use case.

Ohhh did not know that was possible, would be pretty cool to overload them.

That's how the lambdas work more or less.

[L3MON4D3]

The only pain point of using a meta with __call is that it's a bit slower than raw function calls, but I don't know if that will be noticeable in that use case.

Good to know, let's hope it's negligible, I'd really like to make this module independent of the internals :D

That's how the lambdas work more or less.

Right, I remember 👍

I think for memoization to really be worth it, and not just be overhead

• we'd need to check the condition before matching the trigger (The probability that there are multiple snippets with a matching trigger and the same, therefore memoizable, condition seems very low (multiple snippets because I assume, most common conditions would have to be computed at least once per expand-call)) (the problem with condition-first is that matching the trigger is probably faster than all conditions, so this would reduce performance for non-memoized conditions)
• the condition would have to be slow to compute, or only depend on eg. the buffer (so it can be effectively memoized)

But adding condition-objects seems worth it for the logical operators alone