Dependency issue with Markdown and snipmate #68

Closed
mikl opened this Issue Apr 30, 2012 · 4 comments

Comments

Projects
None yet
3 participants

mikl commented Apr 30, 2012

I was cleaning out my installed bundles, noticing I had two instances of snipmate (snipmate and snipMate). I deleted both to let VAM sort out the correct one to install. Now, I'm greeted with this when I start vim:

% vim README.md 
Plugin Name: snipMate ver. 
Script Nr: 2540
dependency chain: snipMate < Markdown
Target: /home/mikl/.dotfiles.git/vim/managed-addons/snipMate
!> Deprecation warning package snipMate:
snipMate is an alias to snipmate now - so use 'snipmate'
Origin: git git://github.com/MarcWeber/snipmate.vim
Plugin snipMate is deprecated, see warning above. Install it?
[N]o, Ye(s):

Only way to get this to go away is to have two copies of snipmate, and that might cause problems elsewhere. Can we mitigate this somehow?

Owner

MarcWeber commented May 1, 2012

Quick fix: edit the plugin-info.json (which should be called addon-info
today, but thats not important) and just patch the name manually.
Ugly, but works.

Longer fix: Write the author to change it.

Even longer fix: Write a patch phase for VAM (overkill if author replies
in a timely manner)

Great that

  • the output of VAM is that great that people start using it for bug
    reports
  • great that foreign people start using the dependency system

Looks like finally my dreams (making plugin management suckles) gets
true.

I'll write the author. Thanks for reporting

Collaborator

ZyX-I commented May 2, 2012

I believe for things that already require loading VAM-kr it should be allowed to use “%SNR” notation, because script number is the only thing that won’t really ever change. For addon-info.txt this will lead to overwriting it though, cycle should be the following: check for exact match, check for %SNR presence (or vim_script_nr key in dependency information), expand it if there is any, check generated name for being equal to original, overwrite if it is not. Don’t allow meaningless %SNR directories, it would be a great step backward.

Owner

MarcWeber commented May 2, 2012

Excerpts from ZyX-I's message of Wed May 02 21:38:30 +0200 2012:

I believe for things that already require loading VAM-kr it should be
allowed to use “%SNR” notation, because script number is the only
thing that won’t really ever change.
Assuming that you want to use "old" ids. Sometimes upstream changes (eg
snipmate) - then you can keep the name and use a new id. I don't know
which happens more often. I know that names are much more readable than
ids. If there are many hints that noise about renaming gets too much -
we can talk about changing it. But I don't see that happening right now.

I'm fine with adding it as suggestion to the bug section to give people
a chance to tell us that they want this to be implemented sooner.

Owner

MarcWeber commented Apr 4, 2013

This bug is obsolete because github.com/MarcWeber/ultisnips can also read snipmate-snippetsn now.
For that reason it does no longer make sense to have snipmate-snippets fetch snipmate. Thus you have to install the engine and the snippets yourself. If there is another similar use case we will have to talk about a nice fix again.

MarcWeber closed this Apr 4, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment