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 precise answers from our community would be pretty useful.

  • 1
    You also have this matrix provided on Marc Weber wiki: vim-wiki.mawercer.de/wiki/topic/… Commented Apr 22, 2016 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
    Commented Apr 22, 2016 at 20:14
  • you should update the wiki with the information from here. thanks. Commented Apr 25, 2016 at 13:38
  • @ChristianBrabandt: Yep as soon as I'll have some time (in the next few days) I'll update it.
    – statox
    Commented Apr 26, 2016 at 7:32
  • fwiw, I appreciate questions of this sort! Seems like it used to be SE policy to frown on Qs like this as being "too open ended" or "inviting opinionated debate" but how else can one gain the insight of more experienced users and build one's own workflow skills?
    – Jeff
    Commented May 6, 2020 at 17:47

4 Answers 4


I've been using ultisnips for several weeks now.

I think the main advantages of this plugin 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 quickly create 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 to 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 vim-snippets.

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

The snippets' definitions 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 specific to a filetype are expanded only when the buffer's filetype is set. A special filetype all is available to create snippets expanded on all buffers.

In addition to the snippets provided by vim-snippets, the user can define its 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 chose ** which is pretty convenient for me). Note that an integration should be possible but I didn't test it by myself).

For power users, Ultisnips also provides some functions 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 used 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 screencasts 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
    Commented Jul 2, 2018 at 15:10

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.

  • 34
    That's the first time I have seen anyone mentioning abandonment as a feature. :D
    – muru
    Commented Apr 22, 2016 at 23:43
  • 12
    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
    Commented Apr 23, 2016 at 9:10
  • 9
    "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
    Commented Apr 26, 2016 at 16:30
  • 2
    There are a few bugs and documentation errors in UltraSnips that make for a less-than-pleasant introductory experience. After finally getting it running, I decided to check out SnipMate and can understand @romainl's argument for stability.
    – chb
    Commented Aug 14, 2018 at 2:14
  • 4
    Abandonment can definitely be a feature. Everything tends to suffer from bloat and die at some point. The economy and thus most business models are built on perpetual growth which is unsustainable. This is how you end up with a windows store that uses 100% of your SSD.
    – eusid
    Commented May 17, 2019 at 12:12

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.

UltiSnips dropped support for python2 on Nov 5, 2019, see Remove support for Python2 #1129. In your .vimrc, load (using Plug) one of the plugins depending on python availability.

if has('python3')
    Plug 'SirVer/ultisnips'
elseif has('python')
    Plug 'SirVer/ultisnips', {
        \   'tag': '3.2',
        \   'dir': get(g:, 'plug_home', '~/.vim/plugged') . '/ultisnips_py2',
        \ }
    Plug 'garbas/vim-snipmate'
    Plug 'MarcWeber/vim-addon-mw-utils' "required for snipmate
    Plug 'tomtom/tlib_vim' "required for snipmate

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) + '┘'`

With this snippet, I can output something like this:

│ this is a cool box! │

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
    Commented Jun 14, 2016 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 Commented Jun 14, 2016 at 7:57
  • 1
    Indeed when I see your link I can understand why some snippets better live in their own files. Thanks for your clarifications.
    – statox
    Commented Jun 14, 2016 at 8:11
  • 2
    @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, ...) Commented Jun 14, 2016 at 8:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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