Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to cope with UltiSnips and snipmate issues? #363

Closed
MarcWeber opened this issue May 6, 2014 · 9 comments
Closed

How to cope with UltiSnips and snipmate issues? #363

MarcWeber opened this issue May 6, 2014 · 9 comments

Comments

@MarcWeber
Copy link
Collaborator

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
Copy link
Contributor

lucc commented May 6, 2014

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
Copy link
Contributor

lucc commented May 6, 2014

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

@MarcWeber
Copy link
Collaborator Author

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

@SirVer
Copy link
Collaborator

SirVer commented May 6, 2014

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 [email protected]:

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
Copy link
Collaborator

SirVer commented May 7, 2014

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
Copy link
Collaborator Author

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
Copy link
Collaborator

SirVer commented May 8, 2014

sgtm.

@honza
Copy link
Owner

honza commented May 22, 2014

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

@polyzen
Copy link

polyzen commented Feb 27, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants