What is the difference between the vim snippets plugins?

Question

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.

Answer 1

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:

• Episode 1: What are snippets and do I need them?
• Episode 2: Creating Basic Snippets
• Episode 3: What's new in version 2.0
• Episode 4: Python Interpolation

Answer 2

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.

Answer 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.

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',
        \ }
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! │
└─────────────────────┘

Answer 4

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)
  3. • 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.