How to cope with UltiSnips and snipmate issues?

[MarcWeber]

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:

• prevent duplication (do it once)
• please users as much as possible

The most simple strategy could be:

• Put simple snippets in .snippets files
• If you have complex advanced alternatives think use UltiSnips files
  judgment of this idea:
• least snippet duplication
• it serves everybody as much as possible, duplicates can be "ignored" by telling engines to use first hit and making sure engines read the .snippet files first
• UltiSnips users have to open and look at two files

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.
There is no hurry.

I commented here that I added those comments to the README:
#355

The first PR following this suggestion appeared shortly after:
#362

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.

[lucc]

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.

[lucc]

Related: The README has two sections on contributing: Policies / for contributors (strange name?) and Contributing notes.

[MarcWeber]

I've merged both sections, thanks for taking care.

[SirVer]

I am busy tonight, but will add comments tomorrow morning. Please do not merge yet.

Am 06.05.2014 um 12:21 schrieb Marc Weber notifications@github.com:

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:

prevent duplication (do it once)
please users as much as possible
The most simple strategy could be:

Put simple snippets in .snippets files
If you have complex advanced alternatives think use UltiSnips files judgment of this idea:
least snippet duplication
it serves everybody as much as possible, duplicates can be "ignored" by telling engines to use first hit and making sure engines read the .snippet files first
UltiSnips users have to open and look at two files
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.
There is no hurry.

I commented here that I added those comments to the README:
#355

The first PR following this suggestion appeared shortly after:
#362

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.

—
Reply to this email directly or view it on GitHub.

[SirVer]

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

[MarcWeber]

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 ?

[SirVer]

sgtm.

[honza]

Holy, moly, ultisnips is on vimcasts. I guess I should get my act together and finally switch to it.

[polyzen]

The consenus is to keep duplicates, no?:

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.

The readme still has:

Currently all snippets from UltiSnips have been put into UltiSnips - some work on merging should be done (dropping duplicates etc).