22

There is a great number of snippets plugins for vim: ultisnips, snipmate, xptemplate, neosnippet and a lot more.

They all have pros and cons and more or less dependencies. So far I've been using ultisnips but never been totally satisfied with it.

As we have a very interesting and complete question about plugin managers I think it would be pretty useful to have the same kind of explanations about snippets plugins.

There is a listing here which could be a good start but some complete, clear and precises answers as our community can write would be pretty useful.

  • 1
    You also have this matrix provided on Marc Weber wiki: vim-wiki.mawercer.de/wiki/topic/… – Luc Hermitte Apr 22 '16 at 16:42
  • 2
    IMHO this is quite generic, perhaps if you elaborate the "never been totally satisfied with it"? I use Shougo's "neosnippet.vim". – VanLaser Apr 22 '16 at 20:14
  • you should update the wiki with the information from here. thanks. – Christian Brabandt Apr 25 '16 at 13:38
  • @ChristianBrabandt: Yep as soon as I'll have some time (in the next few days) I'll update it. – statox Apr 26 '16 at 7:32
18

I've been using ultisnips for several weeks now:

I think the main advantages of this plugins are the following:

  • It is pretty fast even with a great number of snippets available.
  • The basic syntax to define a new snippet is easy to understand, thus it is easy to create quickly a new snippet doing what you want to do. (For more complex snippets some additional work can be required)
  • It works very well out of the box, a basic configuration allow you do use snippets very quickly.
  • It is really configurable. Even if the basic configuration works well, if you're a power user you can really tune it pretty finely.

First of all ultisnips is a snippet engine which means that the plugin provides features to use snippets but doesn't provide the snippets themselves. To get the snippets, the author recommends to use vim-snippets.

Once you got both plugin installed you'll be able to use your snippets.

The snippets definition are stored in files named following patterns: ft.snippets, ft_*.snippets, or ft/*, where ft is the 'filetype' of the current document and * is a shell-like wildcard matching any string including the empty string. (Note that dotted filetype syntax like cuda.cpp is supported)

This way snippets specifics to a filetype are expanded only when the buffer's filetype is set. A special filetype all is available to create snippets expanded on every buffers.

In addition to the snippets provided by vim-snippets, the user can define it's own snippets. My recommendation would be to place them in the directory ~/.vim/my-snippets/Ultisnips this way Ultisnips will find them without additional configuration and it is easy to maintain them in a dotfile repository.

To expand the snippets Ultisnips provides a variable g:UltiSnipsExpandTrigger which defines the mapping which will trigger the expansion (I choose ** which is pretty convenient for me). Note that an integration should be possible but I didn't tested it by myself).

For power users, Ultisnips also provides some function to customize the behavior of the expansion, or to trigger it differently. See :h UltiSnips-trigger-functions


This is the first snippet manager that I really use extensively and I think this is a good one to begin with for its simplicity out of the box and its possibility to be tuned.

Finally here is a list of screencast which give a good introduction to the plugin:

  • Do you know how to make it so that it doesn't expand when triggering unless its preceded by whitespace OR a > (as in closing brace of HTML. The fact it doesnt know its at the end of a tag is annoying, because if I enable the option i then it makes it so it expands it even if its in the middle of a word which is no good. – Tallboy Jul 2 '18 at 15:10
11

I've been using the original SnipMate since I started using Vim.

  • It doesn't have external dependencies.
  • It uses a very simple syntax.
  • It is very easy to set up.
  • It has been abandoned since 2009.

I have nothing to complain about.

  • 12
    That's the first time I have seen anyone mentioning abandonment as a feature. :D – muru Apr 22 '16 at 23:43
  • 5
    An abandoned project is a stable project. You don't need to worry about your local instance being out of date or about an update breaking your workflow with an API change. If it satisfied your needs when you installed it, it will continue to do so forever. Unless your needs change. Stability is the #1 feature I look for in any tool. – romainl Apr 23 '16 at 9:10
  • 3
    "If it satisfied your needs when you installed it, it will continue to do so forever. Unless your needs change." Or you find a bug, at which point you need to fix it yourself, find someone else to fix it, or look for an alternative; one which hasn't been abandoned, perhaps. – user859 Apr 26 '16 at 16:30
  • 1
    Thanks for your answer @romainl! I have one question: You said the plugin is abandoned, but the readme redirects to a newer version which seems pretty active and several commits seems to fix some stuff isn't it better to use the new one? – statox Jun 14 '16 at 8:08
  • @statox, not in my opinion. – romainl Jun 14 '16 at 9:18
7

Here is a list of features from mu-template. Discl.: I'm its maintainer.

  • Template-files can be expanded:
    • automatically when opening a new buffer (unless deactivated from the .vimrc),
    • explicitly through menus or the command line,
    • from the INSERT-mode in a snippet-like fashion ;
    • from the VISUAL-mode to surround the selection with a snippet -- the surrounding may be applied to different zones in the snippet (e.g. code or condition zones in a while control-statement) ;
  • All snippets are defined in their own template-file -- all other snippet engines use one file per filetype and put all snippets in it ;
  • The template-files can be overridden by the user, or in the context of a specific project ;
  • Filetype specific snippets can be defined for the INSERT-mode (they can be inherited, e.g. C snippets can be used from C++, Java, etc.), the list of matching snippets will be presented with a hint for each snippet ;
  • Computed VimL expressions can be inserted ;
  • VimL instructions can be executed during the expansion -- I use it to automatically add missing includes or import statements ;
  • Template-files can include other template-files in a function-like manner (parameters are even supported) -- AFAIK, very few snippet engines implement this, they aren't even able to support snippet aliases, which is trivial to implement thanks to this feature ;
  • Fully integrated with my placeholders-system ;
  • Supports re-indentation (if desired), and Python indentation ;
  • Works well with vim folding ;
  • I18n friendly ;
  • When several snippets match, an advanced completion menu pops up (it has been inspired by YouCompleteMe popup menu) ;
  • Style options are applied automatically (how do you prefer your brackets? if (...) {\n}? if (...)\n{\n}? Something else?), and of course, they can be fine tuned depending on the current project, or the current filetype, or even both ;
  • The plugin is 100% VimL. Python could be used from the template file though.
  • mu-template depends on two library plugins (lh-vim-lib and lh-dev), and on my placeholder system (lh-brackets) -- that's why I recommend to install it with VAM or VimFlavor as I provide the files that declare the dependencies ;
  • The licence is compatible with code generation -- that means that while mu-template code is under GPLv3, the snippets aren't, you can use them in proprietary code: some snippets are under Boost Software Licence though;

  • The expansion happens after any local vimrcs present are loaded -- in order to set project-specific variables before the expansion is done.

  • Thanks to Tom Link's StakeHolders plugin, µTemplate does have tied placeholders (modifying one named placeholder modifies other placeholders with the same name). Not installing Stakeholders will not prevent you from using µTemplate.

To be perfectly honest, the template syntax is a little bit cumbersome, and the placeholder system belongs to the first placeholders generation -- mu-template is one of the oldest template/snippets engine for Vim.

However, the fact it permits snippets to include other snippets (conditionally, and with parameters) which may or may not be overridden is quite important. Typical applications are

  • the C++ file template

    1. which includes a file header (usually fine tuned differently for each project in order to include the right copyright notice)
    2. then load the template best fit for the current type of file (.h, .cpp, or unit test file)
      • in header-file case, anti-reinclusion guards will be included -- the way they are computed may be overridden (again to follow project policies)
      • in .cpp files case, the matching .h file is automatically included if found
  • I have a generic class snippet/wizard in lh-cpp. And several specialized class kinds that use this common class template, but with different parameters.

  • Thanks for your answer! I have a question: you said All snippets are defined in their own template-file -- all other snippet engines use one file per filetype and put all snippets in it what is the advantage of this architecture compared to the usual one (i.e. one file by filetype)? – statox Jun 14 '16 at 7:51
  • @statox I'd say, this is a snippets maintenance issue. Some snippets are excessively complex. Take a look at lh-cpp internals/class-skeleton for instance. I'd rather not have it blended with the control-statement snippets. But I must admit, that having all control statement together wouldn't be that problematic. Moreover, thanks to this approach, I can very easily override my snippets, update them on the fly, use them as functions, etc – Luc Hermitte Jun 14 '16 at 7:57
  • Indeed when I see your link I can understand why some snippets better live in their own files. Thanks for your clarifications. – statox Jun 14 '16 at 8:11
  • 1
    @statox Actually, many snippets I have tend to be complex: they detect, deduce, and try to do as many smart things as possible. Most of the time I move the code to autoloaded functions, but sometimes, it makes more sense to use several snippets that call each others (and act as variation points that can be tuned for project needs -> copyright statements, ...) – Luc Hermitte Jun 14 '16 at 8:19
3

SnipMate and UltiSnips are the two most popular snippet engine for Vim. Both are inspired from TextMate's snippet syntax. UltiSnips can run all SnipMate snippets but also have additional syntax to make it more powerful.

A good rule of thumb is that if your Vim has python support, then use UltiSnips. If not, then use SnipMate.

In my .vimrc, I load (using Plug) either plugin depending on python availability.

if (has('python') || has('python3'))
    Plug 'SirVer/ultisnips'
else
    Plug 'garbas/vim-snipmate'
    Plug 'MarcWeber/vim-addon-mw-utils' "required for snipmate
    Plug 'tomtom/tlib_vim' "required for snipmate
endif

UltiSnips can also run python codes in its snippet, allowing it to do some cool tricks. This is one of my favorite snippet that draws a box around a text (from How I'm able to take notes in mathematics lectures using LaTeX and Vim | Gilles Castel )

snippet box2 "Box"
`!p snip.rv = '┌' + '─' * (len(t[1]) + 2) + '┐'`
│ $1 │
`!p snip.rv = '└' + '─' * (len(t[1]) + 2) + '┘'`
$0
endsnippet

With this snippet, I can output something like this:

┌─────────────────────┐
│ this is a cool box! │
└─────────────────────┘

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.