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

Allow snippet files for multiple dotted filetypes #889

Closed
wants to merge 1 commit into from
Closed

Allow snippet files for multiple dotted filetypes #889

wants to merge 1 commit into from

Conversation

AndrewRadev
Copy link

This PR allows the creation of a foo.bar.snippets file that will get loaded for the combination filetype "foo.bar".

As an example, I have "ruby" and "erb" snippet files that are general-purpose, for any ruby or erb file. For rails projects, I'd like to add a few more snippets to both of these filetypes, but the snippets are different in both. I could create a rails.snippets file that combines the two snippet sets, but it would be impossible to use the same trigger for different snippets.

With this PR, I can create the files rails.ruby.snippets and rails.erb.snippets and organize them properly. I have the same setup for javascript and coffeescript -- similar triggers generate different code, and different ember.js snippets need to be loaded depending on the language used.

If there's an existing way of getting the same results, I don't mind using it and closing the PR. Also, I'm not an experienced python developer, so there may be a more sensible way of implementing that particular function. I'm open to any suggestions to change the code to fit the codebase better.

@SirVer
Copy link
Owner

SirVer commented Apr 1, 2018

Sorry for the late reply.

I do not follow your explanation and hence do not understand the usefulness of the feature you are proposing. I have a hunch that you could get to the same result using clever usage of priorities, but I am not sure. Could you spell out a concrete example with a few snippets and snippet files for me to get it?

Either way, I hope we find another way of getting you what you need. The suggested fix changes the semantics of dotted filetypes away from the one Vim uses internally: now

  1. order of the filteypes matters (cpp.cuda != cuda.cpp) and
  2. cuda.cpp is not only the set of cuda and cpp, but also an additional entity cuda.cpp - which it never is for Vim as far as I know.

I'd like to avoid adding additional semantics as much as possible, since they are confusing for Vim veterans.

@AndrewRadev
Copy link
Author

Imagine I have the following snippet for properties in ember.js projects:

snippet prop
function() {
	${1}
}.property(${2}),
endsnippet

This snippet only make sense for ember projects, and nothing else. There's no point in having it defined in the "javascript" filetype, because it doesn't work in plain javascript.

Of course, how a "project" works is not something Vim understands. From what I see from the ultisnips documentation, one way to fix this would be to define a custom filetype, ember.javascript -- the first part wouldn't really do anything, other than trigger "ember" filetype plugins, and the second part would get all the javascript ftplugin stuff -- syntax, indent, etc.

So what that means is, I can keep general javascript snippets and ember-specific snippets separated like this:

ember.snippets      -> Ember.js-specific javascript snippets
javascript.snippets -> General javascript snippets

The problem is, I've also needed to work with coffeescript files. The snippets I need for ember.js while writing coffeescript are different than the ones I need for writing ember.js with javascript. The "prop" one would look like this:

snippet prop
(->
	${1}
).property(${2}),
endsnippet

So, I'd like to group them like this:

ember.javascript.snippets  -> Ember.js-specific javascript snippets
ember.coffeescript.snippets -> Ember.js-specific coffeescript snippets
javascript.snippets        -> General javascript_snippets
coffeescript.snippets       -> General coffeescript snippets

Unfortunately, I can't do that. I can't just have one ember.snippets file, because it'd have both javascript and coffeescript in there, which means I'd have to use different triggers or wait for a menu to choose one. Both are inconvenient options.

Either way, I hope we find another way of getting you what you need. The suggested fix changes the semantics of dotted filetypes away from the one Vim uses internally: now

That's true, I hadn't realized it. I thought you could define a filetype/ember.javascript.vim file that would only activate on that combination, but it seems it's not the case. A shame, seems to me like a sensible thing for Vim to do. Though you're right there would be a question of the ordering as well.


I do have an alternative idea: Could you expose a public API that would allow someone to define a file with snippets? I see that there's a function called UltiSnips#AddSnippetWithPriority, but that defines a single snippet given its trigger, body, etc. Could you expose a function called, for instance, UltiSnips#AddSnippetFile that would add the snippets in that file for the current filetype? Or for a given filetype? If there's already a function like this, I couldn't find it in the docs.

This is basically how I used to do it with snipMate: https://github.com/AndrewRadev/Vimfiles/blob/3f162b52d571398ffecea4a41295093d538b1160/projects/ember.vim#L5-L6

What do you think?

@SirVer
Copy link
Owner

SirVer commented Apr 8, 2018

Thanks for the explanation. This might work:

  1. Keep your specific snippets in ember_coffeescript.snippets and ember_javascript.snippets. These are not actually used filetypes, but we use them to activate all snippets in those files.
  2. Use :UltiSnipsAddFiletypes ember_javascript in ~/.vim/ftplugin/javascript.vim and similar for coffescript.

This is basically the alternative idea you have been outlining above. Does this work?

@AndrewRadev
Copy link
Author

This works just fine! I should have come up with it myself, honestly, it seems pretty straightforward in hindsight :).

Closing the PR, thank you very much for the help.

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

Successfully merging this pull request may close these issues.

2 participants