Ultisnips: UltiSnips scan the 'snippets' folder in vim-snippets for snippets

Created on 6 Mar 2014  路  17Comments  路  Source: SirVer/ultisnips

I do set

let g:UltiSnipsSnippetDirectories=["UltiSnips"]

even set absolute path

let g:UltiSnipsSnippetDirectories=["~/.vim/bundle/vim-snippets/UltiSnips"]

,But US still searchs snippets in "snippets" folder.

I got

Anr error occured. This is either a bug in UltiSnips or a bug in a
snippet definition. If you think this is a bug, please report it to
https://github.com/SirVer/ultisnips/issues/new.

Following is the full stack trace:
Traceback (most recent call last):
  File "/home/unclebill/.vim/bundle/ultisnips/pythonx/UltiSnips/snippet_manager.py", line 48, in wrapper
    return func(self, *args, **kwds)
  File "/home/unclebill/.vim/bundle/ultisnips/pythonx/UltiSnips/snippet_manager.py", line 136, in snippets_in_current_scope
    snippets = self._snips(before, True)
  File "/home/unclebill/.vim/bundle/ultisnips/pythonx/UltiSnips/snippet_manager.py", line 412, in _snips
    for snippet in source.get_snippets(filetypes, before, possible):
  File "/home/unclebill/.vim/bundle/ultisnips/pythonx/UltiSnips/snippet/source/file/_base.py", line 36, in get_snippets
    self._ensure_loaded(ft, set())
  File "/home/unclebill/.vim/bundle/ultisnips/pythonx/UltiSnips/snippet/source/file/_base.py", line 55, in _ensure_loaded
    self._load_snippets_for(ft)
  File "/home/unclebill/.vim/bundle/ultisnips/pythonx/UltiSnips/snippet/source/file/_base.py", line 79, in _load_snippets_for
    self._parse_snippets(ft, fn)
  File "/home/unclebill/.vim/bundle/ultisnips/pythonx/UltiSnips/snippet/source/file/_base.py", line 95, in _parse_snippets
    raise SnippetSyntaxError(filename, line_index, msg)
SnippetSyntaxError: Invalid line '    var ${1};${2}' in .vim/bundle/vim-snippets/snippets/javascript/javascript.snippets:3

What do I miss? Thanks.

Most helpful comment

Forgive me for commenting on the closed issue, but @SirVer if you consider this a bug/misfeature then perhaps it makes sense to re-open this one:

Now that using the vim-snippets repository is the blessed approach, I'm wondering how I can _ignore_ the SnipMate snippets. There are, for instance, def snippets for Ruby in both snippets and UltiSnips. I don't want to be prompted which to choose -- I don't want the SnipMate one at all. Ditto for some custom snippets I have in my own ~/.vim/UltiSnips versus public SnipMate ones.

Maybe there's an existing way to cope with this, but :echo g:UltiSnipsSnippetDirectories tells me it's ['UltiSnips'] and I find that a bit nonintuitive now that snippets is also now actually being included as well.

Of course we could just delete the snippets directory if they're completely unwanted. But every time I BundleUpdate the snippets with Vundle or set up on a new machine, it's going to come back. Any configurability here that I'm missing?

All 17 comments

Nothing, but this file probably just contains a syntax error (as the error says). Where did you get vim-snippets from? The current line 3:

https://github.com/honza/vim-snippets/blob/master/snippets/javascript/javascript.snippets#L3

looks different. Pull maybe?

It's my fork of honza/vim-snippets with some modification.

But US shouldn't search snippets, right?

just contains a syntax error

Yes, It is. The snippet I wrote is:

snippet     v
{4 spaces here}var ${1};${2}

But US shouldn't search snippets, right?

Well, now it should. UltiSnips reads snipMate snippets now too.

just contains a syntax error

Yes, It is. The snippet I wrote is:

snippet     v
{4 spaces here}var ${1};${2}

snipMate requires tabs at the beginning of the line for a snippet. snipMate should have told you that already, unfortunately it does not notice when it cannot properly parse a snippet.

I am closing this for now. I'll reopen if you have more comments.

Well, now it should. UltiSnips reads snipMate snippets now too.

OK, just know that.

snipMate requires tabs at the beginning of the line for a snippet. snipMate should have told you that already, unfortunately it does not notice when it cannot properly parse a snippet.

Yes,that's my fault.

I am closing this for now. I'll reopen if you have more comments.

I will do.

Thanks! :smiley:

Forgive me for commenting on the closed issue, but @SirVer if you consider this a bug/misfeature then perhaps it makes sense to re-open this one:

Now that using the vim-snippets repository is the blessed approach, I'm wondering how I can _ignore_ the SnipMate snippets. There are, for instance, def snippets for Ruby in both snippets and UltiSnips. I don't want to be prompted which to choose -- I don't want the SnipMate one at all. Ditto for some custom snippets I have in my own ~/.vim/UltiSnips versus public SnipMate ones.

Maybe there's an existing way to cope with this, but :echo g:UltiSnipsSnippetDirectories tells me it's ['UltiSnips'] and I find that a bit nonintuitive now that snippets is also now actually being included as well.

Of course we could just delete the snippets directory if they're completely unwanted. But every time I BundleUpdate the snippets with Vundle or set up on a new machine, it's going to come back. Any configurability here that I'm missing?

Right now there is no way to disable the snipMate snippets - I did this on purpose to get more feedback (like yours). I am not opposed to adding an option for that, but I much rather fix the underlying issues - i.e. more snippets should never be bad.

For example in your case I read that you have to choose which def snippet you want to use. That should never be the case - UltiSnips snippets always override the snipMate defined ones. And for UltiSnips snippets you can define a priority to define which ones are kept. So it sounds like you have another bug/misconfiguration. Could you provide me with a key-for-key example of the behavior that annoys you?

Maybe there's an existing way to cope with this, but :echo g:UltiSnipsSnippetDirectories tells me it's ['UltiSnips'] and I find that a bit nonintuitive now that snippets is also now actually being included as well.

Ah, that depends on the viewpoint I guess. For me this is a configuration variable for the UltiSnips snippet source, not for the Engine. So it is only applied to UltiSnips file searchpath.

Of course we could just delete the snippets directory if they're completely unwanted. But every time I BundleUpdate the snippets with Vundle or set up on a new machine, it's going to come back.

yes, that is not a good solution. If everything else fails we can still add an option to ignore some snippet sources.

For example in your case I read that you have to choose which def snippet you want to use. That should never be the case - UltiSnips snippets always override the snipMate defined ones.

Ah, so I see that I was just unlucky with the example case of what is probably my most-used snippet :smile: I can confirm that my installation/config is working fine, and _with an exact simple match_ an UltiSnips snippet does take precedence over a snipMate one without prompting -- the problem is just that in this case the UltiSnips snippet is a regexp definition of snippet "\b(de)?f" r while the snipMate one is simply snippet def. So I'm being prompted in this case.

Perhaps a clumsy-but-workable solution would be to define separate snippets for def and f -- the public snippets collection might need to trade some DRYness for explicitness or else this may be a common problem where UltiSnip's matching features are much richer than snipMate's :disappointed: Maybe you will have some alternative ideas...

That was a definite bug - I added a test case and fixed it. The question remains if we should have an option to disable snipMate snippets - but for now I feel validated with my approach to hold back on this to learn more about user needs.

Closing this for now as I feel your problem should be solved. If you disagree, please feel free to reopen.

Fantastic, thanks for the quick fix! I agree that for now I don't have any strong desire to disable the snipMate snippets with that behavior being fixed -- as you say, more snippets is a good thing, so long as they don't slow one down with spurious prompts.

I had a similar issue (https://github.com/honza/vim-snippets/issues/440) so I would vote for adding the option to disable snipMate

Similar problem ocurred on a simple HTML file right out of the box.

screen shot 2014-09-23 at 3 51 32 pm

should be fixed now, the problem was that somebody submitted a snippet that did not start with a tab. I do not know what snipmate does with such malformed snippets, otherwise I would just implement the same behavior.

Is this issue fixed already? I use "UltiSnips" and "Vim-snippets" in C++, when I expand "inc", it always give me two options which are annoying (it also load snippets folder, not the Ultisnips folder). Could anyone give me a hint how to fix this?

@wanchaol I don't think that's an UltiSnips fault _per se_, there is no UltiSnips snippet defined for "inc" in the vim-snippets repo. The issue is that the snipMate snippets define two snippets for "inc", one in the cpp file and one in the c file which cpp extends鈥攖hey probably shouldn't do that, but regardless, I would solve it by creating your own copy of the "inc" snippet in your ~/.vim/UltiSnips/c.snippets, then UltiSnips will favor it and not prompt you.

I have the same issue, with my python snippets, I changed the default folder, when I run UltiSnipsEdit it opens the right file but when I do c-tab I have the default list without my new ones ( "t" & "todo").

My vimrc (.vimrc.local 'cause I'm using spf13 conf):

let g:UltiSnipsExpandTrigger="<c-j>"
let g:UltiSnipsJumpForwardTrigger="<c-j>"
let g:UltiSnipsJumpBackwardTrigger="<c-k>"
let g:UltiSnipsSnippetsDir = "~/config/UltiSnips"
let g:UltiSnipsSnippetDirectories=["~/config/UltiSnips"]

~/config/UltiSnips/python.snippets:

snippet todo "TODO reminder" b
    # TODO(`echo $USER`): ${1:desc} `!v strftime("%c")`
endsnippet

snippet t "A simple test"
    Test
endsnippet

@ches Yes you are right! Thanks for the recommendation! I have fixed that.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Alex-Canales picture Alex-Canales  路  4Comments

carlitux picture carlitux  路  3Comments

vanabel picture vanabel  路  7Comments

jonathf picture jonathf  路  6Comments

raorm picture raorm  路  4Comments