Attempt at displaying regTrig snippets in completion menu

[zdcthomas]

I made this because of an issue
I opened on the luasnip repo, but realized that this is something to experiment
with over here.

Sometimes the regTrig snippets dissapear entirely from the list of snippets

I'd love some critique and insight into what I'm doing wrong here, since it
feels fairly flimsy as it is now.

Thanks!

[L3MON4D3]

Right:
I think this is a good approach if one really wants to expand their snippets using cmp (because, well, if the regex-snippet can be expanded through cmp, it can also be expanded with regular expand, so why not just do that :D).
IMO it'd be nice to keep the old behaviour around and expose this as an (some? see below) option (is there support for source-options in cmp or do we have to do that with setup?)

Concerning the issues, I'm not sure what's going wrong, afaict it should all work :/
Maybe some strategic prints?

One more idea to make this option more general: add show_condition(snippet,line_to_cursor) and expand-callback(snippet, line_to_cursor) in cmp_luasnip (I think the snippet and line_to_cursor should be enough info), the proper functions for this functionality could be provided in cmp_luasnip(.extras? :D)

[zdcthomas]

IMO it'd be nice to keep the old behaviour around and expose this as an (some? see below) option (is there support for
source-options in cmp or do we have to do that with setup?)
We can totally do this, but are you sure you want to allow the old behavior at all?

These show what the experience was like with all regex snippets before.

Completion menu:

After expansion:

I totally don't mind, I just want to confirm.

Also, the issue seems to have gone away after reintroducing the cache, but I'll keep testing to make sure.

[L3MON4D3]

Okay for postfix-style snippets where some part (most) of the trigger was probably already typed, the current solution doesn't make much sense, that's true.

But there are other snippet where it works ok I think, for example "heading(%d)" would expand to heading${1:%d}$0, or "(%d%d).(%d%d).(%d%d%d%d)" to ${1:%d%d}.${2:%d%d}.${3:%d%d%d%d}$0.

Just noticed, I don't think I mentioned the general idea with these 😅: one can fill out the variable parts(%something) of the pattern, jump to the end of it and then expand it regularly, making it a bit easier to match the snippet-pattern.

[zdcthomas]

Ohh, very interesting! I had no idea! I probably should've figured that out myself haha 😅
Since that's the case, maybe this PR isn't going in the right direction at all (at least in how it changes the display of the regex snippets)!

[L3MON4D3]

Naaaah, perhaps this should be put in the readme, you're not the first to be confused by this :D

What might work is a hybrid of the two approaches: if the pattern matches, just expand, if it doesn't, expand the helper.
Downside is, that the behaviour of expand depends on the context, which could lead to unexpected behaviour (for example if the pattern of some snippet accidentially matches at some position)