Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
How to cope with UltiSnips and snipmate issues? #363
Historically UltiSnips (depending on Vim with Python) introduced UltiSnippets and Snipmate introduced "snippets" files. Today UltiSnips can read both, but snipmate cannot. UltiSnips has "advanced" features which are useful in some cases such as "nested snippets" and special triggers - Marc Weber never felt need for special triggers in snipmate because it historically had snippet completion while triggering - and passing arguments to snippets by trigger can be emulated by input() which requires hitting one additional time. Thus which features are worth having or not depends heavily on the judgment of the user.
The big question now is: How should vim-snippets cope with it? Nice habits to keep in mind:
The most simple strategy could be:
This is Marc Weber's favorite solution for now. One example following this is "html_minimal" example.
Please use this issue to discuss alternative solutions emphasizing on why they are better/worse than what I'm proposing above (which is already documented in the README).
If you're fine with the proposal only reply if it looks like the thread comes to a different solution. I'd suggest waiting for about 4 weeks for people to put their opinions.
I commented here that I added those comments to the README:
The first PR following this suggestion appeared shortly after:
There is an additional issue: Snippet engines support multiple files anyway: Should there be a simple command which allows finding the file defining a snippet? A simple grep all snippet files being used would be enough probably (eg using grepadd or such). That would be trivial to implement.
I'm sorry I did not read the closed issues. Maybe you can add a "contributing" file or wiki entry to the project. That where the places I checked. I think this problem (new users/contributors violating some agreements) will arise again if the discussion is only in (closed) issues.
I am busy tonight, but will add comments tomorrow morning. Please do not merge yet.
So, I completely misunderstood. I thought you prepared a PR for changes to the README, I did not see that you already pushed it - I would suggest that README changes should go through PR in the future so that we can get some polish and discussion going first and not flip flop on the suggestions we give to users.
Generally I am fine with the proposed solution, however I think duplicates in UltiSnips should not be removed - when somebody started working on UltiSnips triggers it is possible that further development will happen on them that use US features - this is easier when they are all in one file.
New snippets will basically only depend on the engine users use - if somebody uses UltiSnips, they should be added to UltiSnips, if someone uses snipMate, they can go into snippets/.
In fact the advice has been there previously - so the advice to users didn't change much. So maybe we should settle on keep as is if in doubt (to keep things the way users are used to?). This would mean duplication is fine to keep user experience the way they know ?
referenced this issue
Jun 5, 2015
The consenus is to keep duplicates, no?:
The readme still has: