-
Notifications
You must be signed in to change notification settings - Fork 471
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
[Feat request] Avoid assigning multiple snippet sources to a single language #88
Comments
Yes, you're absolutely right. In fact I've been thinking about this for a long time. I never liked the idea of mixing snippets from other frameworks. As you mentioned with Jekyll, the same happens with other snippets that are from a specific frameworks. What I'd like to do is having an option to enable extra snippets for a specific frameworks or whatever. Right now there's a couple of filetypes that have snippets not relevant to the vanilla language. Like for example:
All of that is irrelevant for people not using those frameworks. And should not be included by default. I want all of those to only be enabled through an option, here's the thing, I've no idea on how to approach it. This "plugin" is only json files and I dont know what to do so certain snippets are only available through an option. Any ideas are welcome! |
The way I see it, this repository should be considered only as a snippet source dictionary. Therefore it should only provide snippets related to the language itself by default and provide separately framework snippets (rails, jekyll, vue, etc). Then it should be the job of the snippet engine (LuaSnip for instance) to mix them or provide an option to load multiple snippet files for a given filetype. A fix may be to use a specific field in the package.json to identify framework snippets (and keep the language field in order to specify the related language).
Then snippets engine could only load snippets without the framework field by default and provide an option to also load specific framework ones. As a bonus, by keeping the language field, we could hope that this change would not break a lot of snippet engines that are currently using this repo. @L3MON4D3 (dev of LuaSnip) or maybe @leiserfg, do you have a better idea? |
In vim a file can have several |
I'd agree with setting the language to the framework in the json, most snippet engines have some way of mixing filetypes for a given buffer, so that should work for most users. |
okay I can add the framework key to the snippets that need it. @L3MON4D3 what would be the easiest for you ? you say you would be okay with the Also, should it be a boolean |
I think easiest would be to just reuse |
doesn't that messes up with syntax highlighting ? |
Oh, I meant if |
oh I see
So if I understand correctly, the language field is going to be reuse. And I need to add the framework to the language filed |
We add snippets defined with that language to |
Sorry, I might look I bit stupid but I'm not 100% sure of what exactly I need to do. For example, just adding |
No problem :) If For a file containing only |
Okay I see, thanks for explaining.
What would be the other mechanism ? my problem with setting You mean this mechanism |
Yeah, that's the one. |
How globally ? |
For example: two markdown-buffers, do |
Okay thanks for your time, I'll make the necessary changes. I'll also add instructions in README, so people know how to add extra snippets from frameworks. Downside is that this will only work wit luasnip, but I think is the best choice, I really don't like having a bunch of irrelevant snippets added by default. |
Nice, that's great to hear :D |
In my opinion, it would be better to avoid linking a single language to multiple snippet files.
For instance, snippets for markdown are loaded from global.json, markdown.json and vscode-jekyll-snippets.json. In my personal experience, I do not use jekyll. Therefore, the jekyll-specific snippets are just irrelevant; worse, they even conflict with some custom snippets I have set.
I believe (and so is the developer of luasnip) that it should be the job of the snippet engine to mix the various files according to the desired filetype/framework and not the job of the source to pre-mix them.
What do you think of it?
The text was updated successfully, but these errors were encountered: