feat: implement wordTrig behavior as a condition
#1288
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
>[!NOTE] > Maybe this pr should just be a code example in documentation or > even a post on a luansip community forum. The wordTrig flag will only expand the snippet if the proceeding character is NOT %w or `_`. This is quite useful. The only issue is that the characters on which we negate on hard coded. See here for the actual implementation [snippet.lua#L827](https://github.com/L3MON4D3/LuaSnip/blob/c9b9a22904c97d0eb69ccb9bab76037838326817/lua/luasnip/nodes/snippet.lua#L827) As a result, authors willl turn their plain triggers into regexTrig=true triggers and proceed their regex with a negated capture group. The issue is that the capture group on which the pattern matched, although its negated, still expands with the rest of the trigger. So people have worked around that by doing inserting the capture group back into the snippet. The main examples of latex + neovim users adopting this pattern besides me :), in current repos is in this very helpful article - A very helpful and influential article for those using neovim + LaTeX proposes this injection technique: <https://ejmastnak.com/tutorials/vim-latex/luasnip/#after-a> - Here is one such example of its usage <https://github.com/ejmastnak/dotfiles/blob/29d4e52ab0fef8fc7ff1a3e2f8b78b8dc297ff2f/config/nvim/LuaSnip/tex/math.lua#L384> ## Why the workaround is an issue This is an issue because it can break LuaSnips understanding of parent and child snippets, resulting in broken jump_next() etc. For instance, consider ```text $mbb$ ^ Cursor is here ``` Some latex snippet authors will have their snippet definition for mbb look like s(trig="([^%w])mbb", t("\mathbb{}") The problem is that this consume the leading `$~ character, and even if the snippet re-inserts the `$` back, the parent snippet $$ will be broken. I think the character wordTrig=true uses should be customized A condition seems like the best way to do it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note
Maybe this pr should just be a code example in documentation or
even a post on a luansip community forum. I apologize if so. I do not mean to spam.
Upshot
I think the repo should guide users how to custom the characters used in
wordTrig=true(from the default of[%w_]) . A condition function seems like the best way to do it. This PR attempts to show one such way.The wordTrig flag will only expand the snippet if
the proceeding character is NOT %w or
_.This is quite useful. The only issue is that the characters on which we negate on hard coded. See here for the actual implementation snippet.lua#L827
As a result, authors will turn their plain triggers into
regexTrig=truetriggers and precede their regex with a negated capture group. The capture group on which the pattern is matched, although negated, still expands with the rest of the trigger. So people have worked around that by inserting the capture group back into the snippet via function node.Why the workaround is an issue
This is an issue because it can break LuaSnip's understanding of parent and child snippets, resulting in broken jump_next() etc. For instance, consider
Some latex snippet authors will have their snippet definition for mbb look like s(trig="([^%w])mbb", t("\mathbb{}") The problem is that this consume the leading
$character, and even if the snippet re-inserts the$back, the parent snippet$$will be broken.