Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug with %% snippet from jinja snippets file from vim-snippets #1205

Open
pianocomposer321 opened this issue Jul 5, 2024 · 5 comments
Open

Comments

@pianocomposer321
Copy link
Contributor

The jinja snippets file from vim-snippets has the following two snippets:

snippet %
	{% ${1} %}
snippet %%
	{% ${1:tag_name} %}
	${0}
	{% end$1 %}

At least with my configuration, typing %% and then the expand_or_jump trigger expands the first snippet and leaves the first percent, when I would expect it to expand the second snippet instead. I did try changing the order of the snippet definitions, no change.

@L3MON4D3
Copy link
Owner

Hi :)
you can manually adjust the priority of a snipmate-snippet by providing the priority-keyword on the line above the definition, so

priority 1000
snippet %
	{% ${1} %}
priority 1001
snippet %%
	{% ${1:tag_name} %}
	${0}
	{% end$1 %}

where 1000 is the default, and 1001 should (IIRC) cause %% to be checked first

@pianocomposer321
Copy link
Contributor Author

Interesting, I'll try this out when I can, thanks!

If it works this should be good as a workaround, but I would expect that the snippets file from vim-snippets would work as expected without needed modification. I guess it's possible that it's an issue with the snippets file itself? Is the behavior what you would expect given the snippets file? If so I could file an issue with vim-snippets.

@L3MON4D3
Copy link
Owner

L3MON4D3 commented Jul 12, 2024

Mhmmm, I'd have interpreted this as a clear ambiguity, so expanding either of these is equally correct.. Which snippet-engine were you using before that had your expected behaviour? Is there some spec on how these cases are to be handled?
I'd be open to doing some small modifications, like checking triggers that are longer first for snipmate-sources if it gives us better compatibility, but in general I think it'd be better for the snippet-source to not have such ambiguities.

@pianocomposer321
Copy link
Contributor Author

Hey so sorry I didn't see this until now. I hadn't actually tested this with any other engine, but I assumed that the behavior I get from LuaSnips was not correct since my snippets file was from the vim-snippets plugin, which is mentioned in the README. It does make sense to me for % and %% to be treated as separate snippets by the engine, either by checking length as you suggested or by taking into account the order in the snippets file. I would be willing to check how other engines deal with this case and maybe open an issue with vim-snippets if appropriate, but I'm not sure when I'll have time since school is starting for me shortly.

@L3MON4D3
Copy link
Owner

Oh, no worries :)
If you could check how snipmate behaves, that would be great, I don't think it's a pressing issue (as we have a good workaround), so take your time :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants