2018-02-04 0:12 GMT+03:00 Christian Brabandt <cbli...@256bit.org>: > > On Sa, 03 Feb 2018, Marc Weber wrote: > >> http://vam.mawercer.de/ >> You can add the plugins you want to the input and get the result as .zip >> for windows or linux. > > I have never had the need for that. When I used vimballs, I downloaded > them from vim.org opened them in Vim and was done. No need to download a > zip file from a source I do not really know (and on a old Windows I > would have to download a zip tool first to be able to extract the > content). > > Besides, that was not available like 10 years from now when I mainly > used vimballs. And nowadays github access seems to be possible even in > environments where internet access is very restricted from my > experience, so git clone aka plugin managers work out of the box... > >> vimball does not support dependencies. Yes its simple. > > And how many plugins really need dependencies?
Wrong question. How many plugins would benefit from that? You know, besides plugins actually having dependencies like frameworks (e.g. vim-textobject-user) and plugins which are plugins to another plugins (like deoplete sources), there are at least two considerations as well: 1. Vim is adding new features, some of which can be emulated on top of old ones. With dependencies there could be some “compatibility library” plugin like Python’s `six` which allows both using new features and neither dropping old Vim’s support (with a support of a bunch of LTS distros) nor having to design the compatibility layer in the plugin itself. 2. Vim has a bunch of bad design decisions which are not going to be fixed due to backwards compatibility and some missing features. For example, a thing which is needed for many plugins is defining mappings and commands. But mapping commands by default neither bother checking whether mapping exists, and in any case do not let user override lhs. And commands by default are defined without `-bar` while most plugins command do not really need to have bar part of the argument. Nobody would want to bother user with installing dependency just for that, so solution is either “be cautious when writing code and reimplement something which allows mapping customizations each time you write a plugin” or “have an own library and copy it over to new projects”. Both approaches are error-prone (second less, until you need to fix a bug in that copy-paste) and require different developers to repeat the same work for no real reason. And there are more relatively small, but complicated tasks: e.g. correctly saving and restoring register. Problems could be solved with including some “generic utility library” as a dependency (e.g. tlib), or a number of smaller ones (could not exist without sane package manager), but people for some reason don’t like installing dependencies and developers would not think about adding any not strictly necessary one without having a package manager to do the job both for them (for testing in an isolated environment) and users. > > Vimball is a simple solution to a mostly simple problem (Yes I know, > nowadays you often have more complex plugins that require > post-compilation like YCM or so, nevertheless I bet that for 90% of the > existing plugins a vimball would be good enough.) It is good enough only because there are no other options available. Plugins with dependencies would massively appear only after there is a readily available to most users method of installing them, not the other way around. > > Best, > Christian > -- > Warnung! Spalttabletten sind kein Verhütungsmittel! > > -- > -- > You received this message from the "vim_dev" 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 > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
