Autotrigger conditions

[dtomvan]

Hi, I have a feature request about conditional snippets

Normal conditions already exist: https://github.com/L3MON4D3/LuaSnip/blob/663d54482b11bca1ce94f56993b9f6ab485a13dc/DOC.md?plain=1#L164

These decide wether to show and/or expand at all. I would like it if I could have such a condition for autoexpansion. This would decide wether to autoexpand, but it will always be shown and can be manually expanded. This would be handy for snippets in for example markdown or latex, allowing the user to contextualize autoexpansion of snippets, to avoid errors.

Example: https://castel.dev/post/lecture-notes-1/#context

These kinds of snippets are nice to autoexpand in a mathematical context, like sr. But in another context they would be nice to still have, instead of just never expanding at all.

Current workaround

1. duplicate the snippet with vim.deepcopy in both an autoexpand section and a normal one
2. add the condition to the autoexpand one
3. add the inverse of the condition to the normal one

This way either one of the snippets always expands: either the autoexpand one because the condition is met, or the normal one because the condition isn't met and the autoexpand one is disabled

Proposal

Either a similar autoexpand_condition option in a snippet, or by applying the condition in a different (breaking) way to autoexpand snippets, which would effectively do the same as the workaround I just mentioned.

PS: I very much like your project, keep it up!

[atticus-sullivan]

Sounds interesting. Maybe some kind of a wrapper for snippet() would be a possibility as well (just making that note, I'm not sure if this is better then doing this with an additional option). Not quite sure what you mean by your two proposals. One would mean to introduce a boolean option which decides if a copy with inverted condition is being inserted as well, I guess. But what's the other one?

[L3MON4D3]

Hi! :) I agree, this definitely sounds handy, but I dislike that it's so specific. How about we make the current workaround more comfortable via #420, and then just provide a wrapper around that for this specific usecase?

[atticus-sullivan]

I agree, this definitely sounds handy, but I dislike that it's so specific.

Hm that's right. Maybe then a wrapper in the extras module is actually a nice place for this (my biggest fear with doing this with a wrapper was that effectively using wrapper over wrapper... dosn't sound like a really nice design, but being that specific this shouldn't occur).

How about we make the current workaround more comfortable via https://github.com/L3MON4D3/LuaSnip/issues/420, and then just provide a wrapper around that for this specific usecase?

I don't see how this issue (currently) helps us with this issue as the condition is part of the third argument (the opts table) and as far as I see it #420 only allows us to specify multiple tables for the first argument of s().

[L3MON4D3]

as far as I see it #420 only allows us to specify multiple tables for the first argument of s()

Ah, right, but I think we could extend its scope a bit to include the third argument (not sure whether this should include the parameters of the third arg which actually change behaviour (callbacks, for example). With just conditions, we could use the exact same snippet for multiple of those tables, with the other parameters, we'd have to create new snippets for each table (not 100% sure we could even get away with one snippet for all tables))

[dtomvan]

One would mean to introduce a boolean option which decides if a copy with inverted condition is being inserted as well, I guess. But what's the other one?

The first one: Add a new option (fn(line_to_cursor, matched_trigger, captures) -> bool) for a conditional autoexpand, which decides wether the snippet should autoexpand (the existing condition then decides wether to expand at all)

The second one: Use condition to decide wether to automatically expand on autoexpand snippets. Then all autoexpand snippets would always expand with a keybind, but only automatically when condition is met.

Hope this clarifies my original thoughts a bit. I do like @L3MON4D3's approach to use #420.