`regTrig = true` bug?

[tmillr]

I just created my first snippet after getting luasnip setup with nvim-cmp. It works as expected when I comment out the regTrig = true line and uncomment/use the first trig = line. When I try to use it as shown however (which is what I want, to use a regex/pattern for the trigger), the snippet expands to the value of trig (i.e. wkr?|whichkey|(key)?map). Is this normal?

return {
    s(
        {
            -- trig = "wkr",
            trig = "wkr?|whichkey|(key)?map",
            name = "whichkey",
            regTrig = true,
        },
        fmt(
            [[
                <>.register({<>}, {
                        prefix = <>,
                        mode = <>,
                        buffer = <>,
                        expr = <>,
                        silent = <>,
                        nowait = <>,
                })
]],
            {
                i(1, [[wk]]),
                i(0),
                i(2, [[""]]),
                i(3, [["n"]]),
                i(4, [[nil]]),
                i(5, [[false]]),
                i(6, [[false]]),
                i(7, [[false]]),
            },
            { delimiters = "<>", trim_empty = false }
        )
    ),
}

https://user-images.githubusercontent.com/45028928/195248363-c2ec4700-8ef8-4469-906b-33c469b4e7ab.mov

---

Unrelated side-note: locally_jumpable does not exist on what is returned by require("luasnip") even though it's listed as part of the api in DOC.md

[L3MON4D3]

Yup, the idea is that we have no way of getting the captured text if the snippet is expanded via cmp. So, we expand an intermediary snippet where the variable parts can be filled in, and after jumping through the snippet it should be just before the cursor, and match the trigger-pattern (so the regTrig-snippet can be triggered manually).

BTW: regTrig suggests, unfortunately, that aregex is expected as the trigger. This is not the case, a lua-pattern has to be supplied there. There will be proper support for regexes though, follow #547

For the side-note: yeah it does :P For me at least, not sure what version of luasnip you're on, but I don't think there ever was a commit where this function was documented, but not actually available. Best double-check this again, it might be a symptom of conflicting luasnip-installations (installed through different plugin-managers)

[tmillr]

Yup, the idea is that we have no way of getting the captured text if the snippet is expanded via cmp. So, we expand an intermediary snippet where the variable parts can be filled in, and after jumping through the snippet it should be just before the cursor, and match the trigger-pattern (so the regTrig-snippet can be triggered manually).

I apologize but I'm not able to follow this very well. So, in my/this case, I'd essentially have to trigger/expand the snippet twice? And by "captured text" do you mean the trigger? I realize some pretty advanced things can be done with regTrig and using the match or capture groups inside of custom functions (via functionnode etc.), but I was just using it (or trying to) as a shorthand for defining multiple triggers which would all map to the same snippet. Maybe regTrig's main use-case is for other, more dynamic things and that's why I'm having trouble. It wouldn't be too difficult to define my own function and/or use a loop to define the same snippet with multiple different triggers (regular triggers, not regex).

I've always had some trouble figuring out the distinction between luasnip and cmp, particularly when it comes to snippet expansion/triggering, keymaps, or providing/sorting results (which does which?). It seems like both plugins (can) do snippet expansion? Other than that however, I do understand that generally speaking cmp provides the UI/interface while luasnip provides the actual manually-defined snippets.

BTW: regTrig suggests, unfortunately, that aregex is expected as the trigger. This is not the case, a lua-pattern has to be supplied there. There will be proper support for regexes though, follow #547

Thanks! I knew it was a lua pattern (which are very similar to regex) and I knew they had shortcomings, but I didn't realize those shortcoming were to such an extent that even the alternation char | was unsupported and not in fact a magic/special char. I'll have to go back and fix that. After rereading the docs and playing around a bit more, it seems that ? and the like are unsupported on capture groups as well :/.

For the side-note: yeah it does :P For me at least, not sure what version of luasnip you're on, but I don't think there ever was a commit where this function was documented, but not actually available. Best double-check this again, it might be a symptom of conflicting luasnip-installations (installed through different plugin-managers)

My plugin setup is pretty much the usual/norm (I'm using Plug) and I'm not doing anything too crazy as far as that goes. I did some digging however and I think I figured out the issue. The README recommends using Plug 'L3MON4D3/LuaSnip', {'tag': 'v<CurrentMajor>.*'} for Plug, so likewise my Plug file includes this line:

Plug 'L3MON4D3/LuaSnip', {'tag': 'v1.*'}

...which checks-out the v1.0.0 git tag in a detached head state. I thought maybe I made a typo or was hallucinating because I double-checked earlier today and was still getting nil, but ultimately the issue is that locally_jumpable() was introduced later than the v1.0.0 tag. As for the documentation mentioning it, that's my fault because I was simply viewing the docs in my browser here on GitHub which are the latest docs. I wasn't being careful enough along with assuming that my local installation/repo was at the latest commit/master (in which case the docs here on GH would match my local ones), which it was not. So I suppose the fix for that is either wait for another v1.x.x release or unpin the version and follow HEAD. Or, manually implement custom update behavior for this one plugin.

[L3MON4D3]

I apologize but I'm not able to follow this very well. So, in my/this case, I'd essentially have to trigger/expand the snippet twice?

Yess :sweat_smile:

And by "captured text" do you mean the trigger?

Ah, no, that would be the captured groups in a lua pattern: number:(%d) does capture %d, and we want to make these captures available in the snippet, via snippet.captures[indx] (but the entire matched text can also be accessed as snippet.trigger)

Maybe regTrig's main use-case is for other, more dynamic things and that's why I'm having trouble. It wouldn't be too difficult to define my own function and/or use a loop to define the same snippet with multiple different triggers (regular triggers, not regex).

Yes, exactly :+1: I'd recommend defining multiple snippets for now, there are plans to make this exact usecase more easily achievable (#420)

I've always had some trouble figuring out the distinction between luasnip and cmp, particularly when it comes to snippet expansion/triggering, keymaps, or providing/sorting results (which does which?).

There are two ways: manual expand via ls.expand (eg. type the trigger, press <Tab>, or some other key, and the snippet expands), and selecting the snippet in cmps list, which will also expand the snippet, but without the need to type the trigger (obviously, that's why there is this workaround for getting the capture-groups, there's no way to just generate contextually appropriate captured text)

I thought maybe I made a typo or was hallucinating

Definitely can relate, who hasn't felt like that at least once while debugging code xD

ecause I was simply viewing the docs in my browser here on GitHub which are the latest docs

Oh, that's one downside of following tagged releases instead of just master. In general you can select the version you'd like to view the repo at by clicking on master (top-left, not all the way up there though) and selecting a tagged release. Unfortunately, github doesn't seem to store that, but there probably is some way to redirect links to luasnip to lead to the code+doc of your current version.

So I suppose the fix for that is either wait for another v1.x.x release or unpin the version and follow HEAD. Or, manually implement custom update behavior for this one plugin.

If you need locally_jumpable, there's no reason to wait longer with 1.1.0: there are a few nice features, and bigger changes have been sitting on master for a while, so they should be relatively stable. I'll get that out in a bit.