More trigger-types

[L3MON4D3]

Currently we have regTrig and not regTrig (eg. a plain string), but since lua-patterns are quite limited it would be nice to support full regex via either the soon-to-be included jsregexp or just vims builtin regexes (or just both). One nice interface for this include retiring regTrig (backwards compatibly) and instead introducing an arg triggerType, which can be

• "plain" for just text
• "lua" for a lua-pattern
• "ecma" for ecmascript-regex if jsregexp is available
• "vim" for vim-regex

[leiserfg]

Currently regex:match_str({str} returns a tuple with the position of the full match, and that does not allow passing the matched groups. Adding that API to nvim should be an easy task, because match_str is just wrapping an internal function that returns an object that contains such groups. I was thinking to make the PR myself (I'm a bit scared after around 6 years without touching C/C++), but I'm ok if someone else takes over it. In any case, it's a blocker, at least if we wanna keep the same API for all the triggers.

[L3MON4D3]

Sadly nvim does not expose a way to get the matches of the regex, only the full match. So if we wanna make it, a PR to nvim will be required. I assume if someone wants complex regexes, probably (s)he will want to manipulate the string as well.

@leiserfg couldn't we use matchlist() in this case?

[L3MON4D3]

Currently regex:match_str({str} returns a tuple with the position of the full match, and that does not allow passing the matched groups. Adding that API to nvim should be an easy task, because match_str is just wrapping an internal function that returns an object that contains such groups. I was thinking to make the PR myself (I'm a bit scared after around 6 years without touching C/C++), but I'm ok if someone else takes over it. In any case, it's a blocker, at least if we wanna keep the same API for all the triggers.

Riiight, theres a lua-api to vim-regexes... Yeah it's tempting to use that, true. I'll take a closer look tomorrow, then I'll understand what you are talking about😅

[leiserfg]

We could start with matchlist and then move to a proper lua API once it's in place, with the only inconvenience of being unable to store the compiled regex.

[hiberabyss]

Any convenient way to get regex capture group exclude function node?

I would like to use regex in parse_snippet

[leiserfg]

Sorry I don't get your question.

[hiberabyss]

For example, I have following regex snip:

parse({trig = "for(%a)", regTrig = true}, "for \1"),

How to get the regex capture group 1 in the snip text?

[leiserfg]

We could put them in an environment, in that case, the API could be like:

parse({trig = "for(%a)", regTrig = true}, "for $TRIG_1")

WDTY think @L3MON4D3?

[hiberabyss]

It would be better if parse_snipmate could also support this!

[L3MON4D3]

Uuhm yeah, why not👍

Currently we simulate the captures as Variables for lambda (l.CAPTUREn), it might be nice to remove this special handling in lambda and just let CAPTUREn resolve like the other variables. Downside, of course, is that we'd have to include CAPTURE in our builtin variables (no prefix) (at all, which doesn't feel that nice conceptually, and retroactively, it could technically invalidate already-created environments, so we'd have a breaking change on our hands)

Mhmm, maybe we should just keep these special variables in lambda and avoid all this mess.

I think the envs init would have to be adjusted too, right? It isn't passed the snippet I think

[L3MON4D3]

It would be better if parse_snipmate could also support this!

If it's supported in one, it'll also work in the other :D Right now they use the same parser, snipmate just does some pre-processing for vimscript-evaluation

[hiberabyss]

Thanks for your working!

[hiberabyss]

Is it possible to expand snipmate file syntax to support regex directly?

[leiserfg]

Is it possible to expand snipmate file syntax to support regex directly?

No, that will be a big breaking change.

[leiserfg]

Uuhm yeah, why not+1

Currently we simulate the captures as Variables for lambda (l.CAPTUREn), it might be nice to remove this special handling in lambda and just let CAPTUREn resolve like the other variables. Downside, of course, is that we'd have to include CAPTURE in our builtin variables (no prefix) (at all, which doesn't feel that nice conceptually, and retroactively, it could technically invalidate already-created environments, so we'd have a breaking change on our hands)

Mhmm, maybe we should just keep these special variables in lambda and avoid all this mess.

I think the envs init would have to be adjusted too, right? It isn't passed the snippet I think

Well, there is a way around we don't allow namespaces starting with _ because of a limitation of the old parser (I added an assert intentionally :smile:) so we can just use $_CAPn which won't be a breaking change. The only breaking change will be passing the snippet as a second argument to the eager vars, but that is also not a real breaking change because you can always pass extra arguments to a function.

[L3MON4D3]

Well, there is a way around we don't allow namespaces starting with _ because of a limitation of the old parser (I added an assert intentionally smile) so we can just use $_CAPn which won't be a breaking change.

xD Okay, that's a way around it, but having variables start with an underscore.. I'd rather have the breaking change then :P But I'd be surprised if anyone is affected by this, so it's probably our best course of action

The only breaking change will be passing the snippet as a second argument to the eager vars, but that is also not a real breaking change because you can always pass extra arguments to a function.

Yeah I agree, no breaking change for that

[medwatt]

Sorry for commenting on an old issue, but is there any update on having proper regex support?

[L3MON4D3]

Finally got to this, follow #923 :D