Excerpts from Amit Agarwal's message of Fri Mar 18 04:06:58 +0000 2011: > +AD4 Can you describe briefly what your script does what you didn't find on > +AD4 vim.sf.net? > Currently I am using GLVS for managing my scripts. GLVS was written when git, mercurial etc were less popular. Also one of the goals of VAM is improve code sharing. So a plugin can say it depends on another library / plugin. Eg most of my plugins depend on tlib.
GLVS does not do it (yet). We can discuss again whether my choice was good to use an additional external -addon-info.txt file keeping this info. Example: https://github.com/MarcWeber/vim-addon-async/blob/master/vim-addon-async-addon-info.txt > GLVS is that it does not change anything that I am used to. It keeps the > scripts in the plugin directories, so if I need to copy or back the > directory, I need not worry. You're right. This works well unless a "plugin" distribution starts being a vimball or a zip which means its made up of many files. Example: plugin/A.vim plugin/B.vim doc/A.txt doc/B.txt Now you decide that you want to update B. deleting 2 files is doable. But many plugins have even more files. What about tar xfz into ~/.vim ? Bad idea: The new version of a plugin could have rename A.vim to A-foo.vim. Then you have both: old and new version. So you would have to keep track of files: = plugin A contents.txt: plugin/A.vim doc/A.vim = Then you know what to remove.. (Of course you can write scripts for this ..) So what does VAM do different? The file layout looks like this: vam/ A/ plugin/A.vim doc/A.vim B/ plugin/B.vim doc/B.vim so getting rid of a plugin is as easy as deleting a directory. Because vam (in docs referred to as ~/vim-addons) can be put into ~/.vim/somewhere you can still backup ~/.vim, copy it around and be done. Why not manipulate runtimepath yourself? Because rtp handing of Vim is not perfect. eg after/*/*.vim files are not sourced at all. > Also the database for the scripts is in another script, which I did not > like. Any addition in vim site would require addition of the same in > this script. You don't have to use it. You can copy paste the sources you care about into your ~/.vimrc then its more like PATHOGEN. However there are reasons for this external additional "script": 1) a way to point users to enhanced versions. The option to "deprecate" scripts 2) add git/mercurial/.. sources of plugins (which may not even be on vim.sf.net) 3) some plugins have bad plugin type. So the extra script fixes them. (Its only about 8-10 plugins. Still VAM tries to get it right for the user the first time. So some minimal patch patching has to be done ..) Again - these feature could be put on vim.sf.net. However when I wrote VAM i wasn't in touch with Bram - so changing the homepage was no option. Adding an upstream url to the scripts is on my TODO. Then you can associate git or mercurial sources with your script. Currently the section of deprecated plugins is small. But we can improve it over time: " deprecations {{{1 let s:plugin_sources['scala']['deprecated'] = "The syntax doesn't highlight \"\"\" strings correctly. I don't know how to contact the maintainer. So I moved the file and a fix into vim-addon-scala" let s:plugin_sources['rubycomplete']['deprecated'] = "you should consider using ruby-vim instead" let s:plugin_sources['idutils']['deprecated'] = "greputils supersedes this plugin" let s:scm_plugin_sources['snipmate']['deprecated'] = "Consider using my fork snipMate because it autoreloads your snippet files and automatically fixes indentation (visually select snippet then <cr>)" "}}} The other reason is that I didn't think of getting a list of plugins the way you did. I iterate over all script?nr=.. urls using VimL regex to extract the info out of the HTML. (which was quite a lot of work to get right) and which takes time. So I want to fix this in the future by introducing an API. I thought it would be benefical to get as much info as possible so that browsing the list could be implemented later (which never happened ..) If a maintained set of plugin is not what users want we can easily ask all users to fetch the info about available plugins from vim.sf.net's API instead. However 1) and 2) mentioned above will not be available. If 1) and 2) was implemented on vim.sf.net using a shell script can turn into a night mare more easily. Shell scripts don't scale very well. I tried getting a patch into top-git once. And I'm sure it took more than twice the time it should have take only because it was written in bash only. Your script is still simple so its ok to use bash. But if you tried adding features such as untarring, ... > +AD4 (or a similar plugin) so that it also runs on Windows and that more > +AD4 users will have access to it naturally? > I would not say no. But I would be interested only in plugins that do > not change the way the directory is structured. I also would be very > much interested in one single solution. I hope you understood that the way is not really changed. Each plugin is put into its own directory instead. Also some additional files are kept: - the original archive (so that diffing can be done when a plugin can be updated) - the plugin versions (so that VAM knows which plugin to update) I agree that the effort VAM does doesn't make sense if you use only 3-4 plugins containing a single .vim file only. Today I'd like to propagate this plugin layout: plugin/A.vim (the user interfac: mappings, commands and autocommands) autoload/A.vim (the implementation: loaded only "as needed") and of course a doc or a README file So all plugins I will write will always have about 3 files at least. > They are not bad if used properly. I made a mistake of not posting the > code correctly. Will be correcting it over the weekend. Having some indentation improves the credibility a lot. Anyway: I'll take a note and I'll add your script to the related work section of VAM in some days because it is somewhat related. Marc Weber -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
