what about merging with ultisnips using its engine?

[MarcWeber]

Dear fellow snipmate community. It was a great honor working for you. github.com/honza/snipmate-snippets is a success - there are many contributions.

However for quite a long time snipmate has been broken in various ways - and me and Rok wonder whether its worth fixing snipmate - cause there are other snippet engines for Vim which are more powerful and which do just work - such as ultisnips or xptemplate.

Ultisnips is much closer to snipmate than xptepmlate - it also supports nested snippets. Ultisnips itself states that it has been copying lots of snippets from snipmate-snippets anyway.

I just feel the wealth for all would be bigger if we'd merge. Most bugs would be gone etc. Less work for maintainers etc.

The only downside is that ultisnips requires python. I'm not sure whether its bad, cause VImL has many flaws anyway - and python is the scripting language which is being used most by plugin authors after VimL.

By this issue I want to ask you - the snipmate user - whether you'd follow such kind of merge and if not why. This merge would mean short-term:

• splitting ultisnip core engine from ultisnips snippets
• merging ultisnips snippets with snipmate-snippets
• adding missing features we love to ultisnips, if any such as the :SnipmateOpenSnippetFiles command,
  make it read sninppets found in &rtp by default and things like that.

Comment on this issue and tell us what you think.

[jmlucjav]

+1 I have been switching snippets plugings, from snipmate to ultisnips now to neocomplcache. But I'm having issues and was going back to snipmate. If this goes through it would be a plus for me.

Regarding python requirement is no issue for me. I installed it to use other plugins too.

[MarcWeber]

Which issues have you had? If you don't talk about them they can't be fixed.

[jmlucjav]

sorry, I meant I am having issues with neocomplcache/neosnippets so I am going to move back to snipmate. I moved to ultisnips before from snipmate cause it was more flexible.

[MarcWeber]

Why are you moving back to snipmate if ultisnips is more flexible?

[jmlucjav]

Cause I prefer now the most used/stable/tested one, that will probably better integrate with others such as autocompletion plugins.

[MarcWeber]

Funny that all people get the impression that snipmate is the most tested one.. Its broken in various ways.

[marlun]

I use vim on a lot of servers where vim might not have python support and where I can't "fix vim" so that it do. Changing snipmate into requiring python would not be very good for that kind of problem.

[MarcWeber]

Don't worry. snipmate will always be what it is now. No python requirement. The worst thing which may happen is that I'll stop working on it - switching to UltiSnips.

Which kind of editing are you doing and how often are you using snippets? Eg when I have to edit a .htaccess file on a server I'm fine starting a local vim instance, doing the snippet expansion there then copying the result to the server. I seldomly have to code on a server.

My current plans are to make UltiSnip read snippet files - or improve it in some ways which I did for snipmate. Thanks for your feedback.

[marlun]

Thinking about it I mostly do editing on servers and coding locally so you are correct in that I don't use snipmate that much on the server. I do however like the idea of things made in VimL since they work pretty much everywhere.

[SirVer]

You basically have a three choices: VimL, which means no automated tests and limited features, but working everywhere or Python which adds some levels of possibilities, some 400 automated tests, a ton of features, speed and cuts the dependencies on other plugins to zero. For me the choice was very simple (that is why I made Ultisnips in the first place). I edit my files on server all via SSH and I have not encountered a server in the last 4 years where a Vim with python wasn't one sudo away. En plus, snipMate will just no longer be maintained (if the Ultisnips merger works well), since Vim is not really developed anymore, snipMate will only bitrot very slowly, so you can just keep using it.

That you like the idea of stuff made in VimL shows me that you have not really used it extensively. Vim would have much more awesome plugins if its scripting language would have been ruby, python or perl instead of a poor homebrew solution. Just take other text editors like sublime or textmate as example. Just my 2c of course.

[marlun]

SirVer as I wrote I like the idea of things made in VimL because it works everywhere, not because I believe VimL is a good language to use. Python is actually my favorite language even though I havn't used it as much as other languages (and maybe thats why I still like it as much as I do :)

The servers that I use where vim doesn't support python is customer servers where I'm not allowed to install new software.

I actually decided to try UltiSnips earlier today because when I thought about it I believe I can live with not having snippets work on those servers and I like what I read about UltiSnips. I actually believe I'll change my mind and agree that you should move on from snipmate.

[MarcWeber]

SirVer: You haven't done that much VimL either - so you can't judge VimL :) Let's just help each other so that we end up having one piece of software we all love, contribute to and maintain. There are also some things snipmate does better, such as showing a popup menu if you only type some chars of a snippet. That makes a big difference, cause you don't have to use different keys. I just don't have time to implement it right now.
My fork is official - when and what will be merged upstream to UltiSnips has to be discussed later with SirVer.
There are little things I still broke such as bbox. It still expands snipmate snippets so I can give it a real try now.

Give it a try, -provide feedback, file snipmate snippets related bugs against my issue tracker.

[honza]

+1 for the merge

[SirVer]

Marc, fair enough. However, I tried to learn Vimscript prior to starting UltiSnips, so I have a basic understanding of its weaknesses though :). I like the popup menu, I meant to implement it for Ultisnips for a long time now. I take a look at how you did it. I need some more time before I can properly review your branch, I will do it though.

[voyeg3r]

+1 for the merge ...

... I have rapidly adapted to ultisnips, I don't see any problem in make this exchange, especially thinking on develloper side, indubitably python open mutch more possibilidties.

I guess insist's in snipmate at this point is a lack of vision in the great new possibilities that we have. I am extremely grateful for all work done on snipmate past. My vote is yes, the community must turn to the ultisnips with all his strength

[idbrii]

+1 for merge.

SnipMate is frustrating me more and more recently (especially #43), but I haven't had time to get the completion menu into ultisnip. (That's the main thing holding me back when I gave ultisnip a quick look.) Bringing the best features over and more bug fixes sounds fantastic.

Either way this goes, thanks for your work on snipmate.

[MarcWeber]

Try my branch (see snipmate-snippets README). There is the show list feature (). Its not as nice, but get's the job done.

[matael]

👍 for this merge. That would be powerful

[Robert-C]

This has to be a joke.

The world doesn't need another project dependent on a garbage language like Python.

[MarcWeber]

Robert-C: VimL is garbage, too (eventually even more garbage). The world does not need such a language either. It even hurts Vim a lot in many ways.
Python is widely used. Python is much more powerful and faster. Whether its python/ruby/something else doesn't matter, vim would benefit from switching and dropping viml - but it cannot be done. I've written enough VimL code being able to judge it. Learning viml is kind a waste of time. People have started implementing crappy xml libraries in viml (I even use it, because I wrote vim-addon-xdebug). But I first used it, then noticed that it was buggy, then had to fix it for more than 6h
to write my plugin. That's the VimL world in quite a lot of cases. And even then the results are slow and don't scale.
You maybe missing this experience which is why I'm telling you. I'd still be interested in which ways you experienced python being garbage so that I can avoid those experiences :)
On my TODO list there is "Add js support for Vim" for more than one year - because everybody doing web development knows some JS - and almost every language can be compiled to JS for that reason. An JS with jitting is very fast today. However I don't get payed for this so there is still no support. However JS would be a problem eventually, too. Because file IO is based on callbacks which doesn't fit the design of Vim's C code nicely. Maybe there are ways to introduce blocking / waiting or such.
Also please note that UltiSnips mainly depends on python, there are no additional python libraries to be installed.

If you want to give the ultisnips implementation (my fork, see README) a try, you're welcome, because UltiSnips does not suffer from some annoying snipmate engine bugs. (such as using numbers in count substitution in for loops not being replaced anywhere). If you've not hit such bugs - nobody is going to delete the snipmate repos, you can continue using it.

Thus the "merge implementation" currently is in this state: snipate users can use UltiSnips to read 98% of their existing snippet files. Thus the snipmate-snippets repo can be used.

If you feel different you're welcome contributing to the snipmate-snippets repo contiuning to use (less maintained) snipmate. There is also xptemplate which is very powerful. But its snippet syntax is that different that porting the snippets would have been a lot of work. For this reason it was no option for me.

There are two more implementations: SimpleSnip and neo-snippets or such. The first doesn't reload snippets automatically, so you always have to remember how to reload them. The second I haven't looked a it. even though
it said to be able to load snipmate snippets I recall that there have been some issues.

Even if we slightly disagree I hope that you agree on allowing to use snipmate-snippets with UltiSnippets is the right choice maximizing collaboration at least on the snippets.

If you feel differently its fine. My goal is to make using vim easy for the average user and for me.

Your feedback is welcome. I hope I could make it easier for you to understand some more about the reasons for this choice.

[ajpaulson]

To those complaining that they have to use vim on servers where python support is not available - vim has built in functionality to edit a remote file on your local machine. You don't have to use the version of Vim on the server.

[sashahart]

You could also use sshfs. You could also do proper deploys (so that you are not just hacking files on remote servers ad-hoc without reproducibility or an audit trail - if it is really important not to install Python on a machine, it's probably also important not to make changes without recording them). You can also just tough it out and use snippets on your local, comfy dev machines without insisting on snippets every time you want to edit an /etc/hosts file using a remote vim. This is a matter of preference, not necessity.

But even as a Python fanatic who will almost never use vim without Python, I can understand why some people wouldn't want the dependency, and this can have an effect on plugin adoption. If you look at the example of the popular and very good Command-T plugin, its requirement of Ruby made the installation process somewhat complex and I think this helped CtrlP (pure VimL) gain a lot of mindshare very fast.

In any case I think it is really cool that the snippet format seems to be converging on a de facto standard, which (IMHO) reduces the importance of everyone choosing to use the same plugin. If people want to use garbas/vim-snipmate to avoid Python dependency then it is reasonable for them not to get fancy Ultisnips features like recursive snippets. So, I am hoping for Ultisnips master to soon understand snipmate snippets if it doesn't already. And then Ultisnips could pick up some users just by offering extra features and speed or whatever, without requiring as much migration effort or 'lockin' as it has in the past.

[MarcWeber]

1. Command-T always has been bloated. You can get very good results using plain old find and grep.
2. If you can't use python, keep using snipmate the way it is.
3. The author admitted that he does not do it that often, and that expanding snippets in Vim running on his local dev machine would be bearable.
4. It does understand snipmate snippets on the fly. See instructions at honza/snipmate-snippets option 3. There are some minor bugs, but 95% do work out of the box - and if there are errors you can fix them because quickfix is populated.
   That branch also implements a similar nice snippet completion the way snipmate does.

What really is still left to do is making all test cases work again. For my case its good enough - I can't afford spending days on those test cases.

Everybody who wants to follow is welcome - and the rest is welcome to continue using snipmate with all its features and bugs.

[ajpaulson]

@sashahart I think you can import snipmate snippets into ultisnips already.

I agree that a standard of writing snippets is a good idea so that the snippet engine itself can be whatever you wish.

[kul]

guys just off topic but can we have update on the README for ultisnip on how to install using vundle, pathogen or manual etc.

[MarcWeber]

You forgot to mention vim-addon-manager, the most advanced packaging solution for VIm today because it knows about dependencies, can load plugins at runtime as needed etc.
I've killed the snipmate-merge branch making master the default so that you all can install this branch more easily:
https://github.com/MarcWeber/UltiSnips

[SirVer]

Kul, how about you write one and send a pull request to sirver/ultisnips? :)

[Evanlec]

@MarcWeber So whats the difference between your UltiSnips branch and sirver/ultisnips ?
I have yours installed now and it seems to be working fine, though I haven't found a guide on exactly how to have it pickup snippets from the snipmate-snippets plugin

[MarcWeber]

Hi Evanlec,

Please have a look at all documentation which is referenced by the README.rst file:
https://github.com/MarcWeber/UltiSnips
It should answer all your questions now.

[MarcWeber]

I've moved UltiSnips snippets into snipmate-snippets repository now.

[Profpatsch]

It looks like the vim community needs a place where they can find all the most recent alternatives they have.

• vim.org/scripts is … um … kind of crappy and anything but up to date.
• Blog entries and screencasts (Steve Losh ftw!) are a good source, yet they mostly steal your time (digging for gold) and are (by their nature) not updated. I mostly use these to find new plugins.
• GitHub:
  • Not every plugin is on GitHub
  • There are often 5 “official” plugins scattered somewhere in 100+ forks

I propose starting a repo with docs listing the crème de la crème, as a combined effort of some active plugin writers and open to contribution.

[mindfulmonk]

For vim plugins I go through most watched https://github.com/languages/VimL/most_watched and there is also http://vim-scripts.org/vim/scripts.html

For plugins on github it's simple just look at the stars

[Profpatsch]

There are several problems with these strategies:

Most watched: They aren’t sorted by any category.
vim-scripts: They aren’t sorted, neither is there any preselection. It’s just a looong list (of which I guess 90% are either worthless, outdated or buggy).
Stars: https://github.com/msanders/snipmate.vim vs. https://github.com/garbas/vim-snipmate is all I can say.

For all these points: Finding the best plugin is a huge time consumer and a matter of trial and error.

[SirVer]

Okay, I finally seem to have some more time these days. So I am committing to merging Marc's changes back into UltiSnips and move forward with the vision of v3.0 - I made a new branch with this name in my repository and will keep working on this.

There are some big todos there: first, every test is broken. This was not an issue for Marc - I find this a little funny, since he stated that adding stuff to snipMate is so hard because you always break something unrelated. I feel the only reason this is not the case with UltiSnips is the test suite - so I will start out with fixing this one.

Secondly, Marc had the ease of transition for snipMate users in mind - that will be a goal for v3.0 as well, but UltiSnips backwards compatibilty must be restored as well. I am fine with a new best practice in many cases, but the old ways should work whenever feasible.

Third: the UltiSnips snippets will me merged into the common repository that honza is maintaining and UltiSnips will only be the engine from v3.0 on.

to top it off, the documentation will need a lot of cleanup and rewriting and I want to make another screencast for v3.0. This will be a ton of work. If someone is interested in joining, please speak up and we can figure out how to part the workload.

[zhaocai]

@Profpatsch

For all these points: Finding the best plugin is a huge time consumer and a matter of trial and error.

Agree! Hope there is a better way.

[MarcWeber]

Hi SirVer, please don't get me wrong: There are important features (providing values to users) - and there are features which don't matter that much. It is ton of work - which is why I decided that I could provide much more value to community in different ways.
Please keep in mind the 20/80 rule: Try to achieve 80% of value by spending 20% of time.

Same applies to documentation: 20% of the documentation is providing 80% of value to users.
That's why I started the QuickStart guide. And reading such 160 lines should get everybody
started fast.

Additional corner cases can even be replied to by github issues usually. (MHO)

So think twice about what really matters to your project. Live is short. Being lazy sometimes is a feature, not a problem :)

[zhaocai]

Being lazy sometimes is a feature, not a problem :)

Agree.

@SirVer Actually, I checkout the ultisnips ver 3 branch and scanned the changelog. But I am not getting what is the actual goal of ver 3. I guess it is to support snipmate snippets at running time.

[SirVer]

@MarcWeber We agree on the 80%/20%, but we do not agree on the importance of features :). A rock solid plugin is more important than fancy features which break from time to time, because when a plugin breaks, it usually takes a good chunk of working time out of the users day. Also, the current situation around snippets is not ideal and doesn't makes it easy for users at all:

• there are too many snippet plugins, all have their share of problems.
• Ultisnips is stretched too thin: being partly on launchpad, partly on github, having too many forks and at least two branches (yours and the main branch) and too much hard to digest documentation. I hope to fix this with 3.0 by convincing you that your branch is no longer needed (soon), move everything to github and providing better entry points to the docu. Also making honzos snippet repo the official one will help a lot too, I guess.

@zhaocai You are right. I added a section to the merge todo about my goals. The list is incomplete, but it is a start.

[Profpatsch]

@MarcWeber Actually the quickstart page didn’t help me at all. The qs is good if you want exactly the same configuration, otherwise completely useless.

And since Ultisnips’ normal documentation is so well written, it’s equally fast to skim it for the functions you need and setting them up with the help of the very good and easy to follow examples. If you are familiar with plugins in vim.

If you are not, the only thing that the qs is better with is for copy-pasting the example.

[MarcWeber]

Profpatsch: In which way does your setup differ from the sample? So how can we learn from your feedback?

I mean something else: UltiSnip has had a huge test suite - but what really matters to me is the new vim snippet completion when hitting much more. Also simple commands like :UltiSnipEdit make a huge difference to me.

Tracking down regressions can be done fast using git (if you know how to do it). But that's my view - and I'm a dev.

The big problem about many open source features is: Lack of feedback. If something doesn't work for users (even if its their fault) - they tend to skip and try something else without telling. And if devs try to setup usage statistics small minorities say "We don't want the system to send data". However no feedback, no progress.

However code review - and having multiple people care about a project almost always improves it very much. So your feedback is appreciated. Keep telling about what you observe

[Profpatsch]

Hm, maybe my setup is very similar, but I can’t tell.

Now that I looked at the qs again, I can say, why:

   " Use old snipmates default mappings (look them up in
    " plugin/UltiSnips.vim)
    " ExpandTrigger, ListSnippets, JumpForwardTrigger, JumpBackwardTrigger
    " yourself. Eg use <c-j> to jump to next placeholder, which is UltiSnips
    " default. It makes sense to use a different mapping so that you don't
    " expand var names. in for loops if they also represent a snippet.

It is nearly not possible to grasp what you want to tell the reader. It doesn’t make sense. And that’s not the only part where that happens.
You should read over your documentation at least once before seeing it as finished, so that sentences are at least grammatically valid and understandable, otherwise no documentation would be a better time-saver.

[MarcWeber]

Thanks - I've tried enhancing that comment. The real problem was that patching UltiSnips took about 2 days longer than I expected.. :(

[lfilho]

Hey, just stopping by to congratulate HOW you guys @MarcWeber and @SirVer are handling this. Just read the full thread and you are being very diplomatic, educated and really trying, each one with your own focus and opinions, do a great piece of software. And of course: free, open source. That is RARE and that deserves a congratulation! Keep up the good work!

[ajzafar]

I'm going to go ahead and close this since it's decided that MarcWeber will primarily be working on UltiSnips while I keep things going with SnipMate.

[SirVer]

I am making good progress with version ultisnips 2.0. I kept most of marcs changes to the vimscript part of ultisnips while reverting most of the python changes. I have a parser that can find and read all of the snipMate snippets I found and I am tweaking various things right now.

I think the merge will soonish be complete.

[MarcWeber]

Having to reload snippets manually is not an option to me. And that was
one of the reasons why I had to rewrite the "python code".
I'll be patient and see how your new release will look like.

In the end I don't care, because both engines (snipmate and my ultisnips
fork) work reasonable well now.

[SirVer]

You never had to reload snippets manually in UltiSnips - the code stats all files and keeps track of when they change and reloads them on the fly. You added a completion menu though - something that will come in version 2.0 too.

[MarcWeber]

#124 (referencing this because most people on this thread might be interested in this)

[SirVer]

fwiw, UltiSnips is now a drop in replacement for snipMate supporting all its features and properly emulating its shortcoming to create the same snippets.

[MarcWeber]

Excerpts from Holger Rapp's message of Wed Feb 26 07:59:12 +0000 2014:

fwiw, UltiSnips is now a drop in replacement
g:snipmate.snipMateSources is not supported
g:snipMate.get_snippets is not supported

So talking about it being a "drop in replacement" is still too much if
you depend on such features (I'm unsure whether its worth implementing
them .. people are happy otherwise they'd create bug reports).

neovim.org might change everything anyway (focusing on lua) but will
also care about python. So I'm unsure how much additional time to spend.
In the end most solutions work good enough.

[SirVer]

It is a not an API drop in replacement, but feature wise it is complete.

g:snipmate.snipMateSources is not supported

The configuartion looks different, but equivalent features are supported.

g:snipMate.get_snippets is not supported

It has another name for ultisnips and returns data in another format. So no API drop in (plugins needs to be adapted).
https://github.com/SirVer/ultisnips/blob/master/autoload/UltiSnips.vim#L89

neovim.org might change everything anyway (focusing on lua) but will

having written > 200.000 lines of Lua in my professional live I have doubts about relying on it as a general purpose scripting language. I am following neosnippets closely, but I am not holding my breath right now.

[MarcWeber]

Would you mind creating an issue @ neosnippets talking about your experience ? Maybe you can influence priorities a little bit this way. I also doubted that translating viml to lua makes sense - at least without confirmation that translating to llvm or such isn't better etc.

Do you think you can provide two patches? One pushing the UltiSnips snippet files (and license stuff) - then we can get those changes in fast (should have been done much earlier anyway).

We could discuss README changes in another pull request then. The faster we merge, the better.

About "full replacement":
At the bottom has "minimal configurations" showing how to use plugin managers (most important features).
http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html

I'd like to introduce something similar here:
http://vim-wiki.mawercer.de/wiki/topic/text-snippets-skeletons-templates.html

Would you mind copy pasting a minimal sample of your UltiSnips config there illustrating such usage and .snippet file selection?
Just add such at the bottom:

 **UltiSnips (SirVer) config example**:
 {{{
 code
 }}}

(sketching it is enough)
I'll improve the other examples later then.

[Shougo]

Hi, I'm author of neosnippet.

having written > 200.000 lines of Lua in my professional live I have doubts about relying on it as a general purpose scripting language. I am following neosnippets closely, but I am not holding my breath right now.

Yes. Lua is fast and small language, so it does not replace Python.

Would you mind creating an issue @ neosnippets talking about your experience ? Maybe you can influence priorities a little bit this way. I also doubted that translating viml to lua makes sense - at least without confirmation that translating to llvm or such isn't better etc.

I think the difference of neosnippet and UltiSnips: neosnippet is marker based snippet engine but UltiSnips is not.
I think marker snippet engine has advantages and disadvantages.
So, if you don't want to use marker based snippet engine, you must use other snippet engines like snipMate/UltiSnips.

[MarcWeber]

neovim/neovim#169

[SirVer]

@Shougo Sorry that we dragged you into this discussion - we actually talked about neovim and somehow got confused and wrote neosnippets everywhere. This was not about your plugin.

@MarcWeber I'll address your other suggestions later this week or on the weekend. I'll also craft a merge request with the parts that we are in agreement on.

[Shougo]

Sorry that we dragged you into this discussion - we actually talked about neovim and somehow got confused and wrote neosnippets everywhere. This was not about your plugin.

Oh, I get it. Thanks.