2016-02-09 15:38 GMT+03:00 Tony Mechelynck <[email protected]>: > On Tue, Feb 9, 2016 at 12:54 PM, Nikolay Aleksandrovich Pavlov > <[email protected]> wrote: >> 2016-02-09 13:03 GMT+03:00 Bram Moolenaar <[email protected]>: >>> >>> I had another idea. Currently when installing a plugin or support for >>> a language, the files are scattered over different directories under >>> $VIMRUNTIME. That makes it hard to update them. >>> >>> How about this: use $VIMRUNTIME/bundles. Below that will be the >>> directories that are usually directly under $VIMRUNTIME. For example, >>> netrw would be installed in the directories: >>> $VIMRUNTIME/bundles/netrw/plugin >>> $VIMRUNTIME/bundles/netrw/autoload >>> $VIMRUNTIME/bundles/netrw/syntax >>> It doesn't need an "indent" directory. >>> >>> That way the directory can be put under version control or updated in >>> any other way easily. E.g. unpacking a zip archive that you get from >>> Charles's site. And it's also easy to get rid of: delete the directory >>> below bundles. No need to hunt down the files that you unpacked before. >>> >>> This also makes it easier for plugin managers. No need to keep adding >>> more and more entries to 'runtimepath'. >> >> This way VAM, Vundle and other non-pathogen users will have move >> plugins out of ~/.vim/bundles. Neither of mentioned plugin managers >> put *all* plugins found in ~/.vim/bundles to &runtimepath, they put >> only those that were *requested by user*. This may also be used to >> conditionally enable plugins. Or to install plugins for a trial and >> use it only in one of many Vim instances during the trial. >> >> So direct consequence of this is that bundles directory could no >> longer be used by all (pathogen is not the one) plugin managers in a >> way they use it currently. > > What about having packages that can be enabled/disabled in some other > directory? (let's say $VIMRUNTIME/packages) — which would not be > checked for plugins, ftplugins, syntax scripts, keymaps, colorschemes, > etc.; then in order to enable package foobar, add in > $VIMRUNTIME/bundles a symlink foobar -> ../packages/foobar. Or even > simply move packages into and out of bundles/ (and, in this example, > out of and into packages) to enable or disable them? (N.B. I'm not > sure about modern Windows, but on Linux the "move" operation moves > only the directory entry when the directories moved-to and moved-from > are in the same filesystem aka the same disk partition.)
I am reporting the current state. There are sure some workarounds (and moving directories is not a good one), but still such change will break. Issues with moving directories: 1. Least significant is that plugins need to be searched in different folders (symlinking: when removing a plugin one needs to care about). 2. And most significant: you cannot conditionally enable plugin from the vimrc for a subset of Vim instances using the same algorythm, so why bother writing two algorythms at all? I would just move managed plugins from ~/.vim/bundles and ignore new functionality. --- I also have forgot one major downside: e.g. my translit3 plugin looks for its configuration by iterating over &runtimepath. There are many other plugins (especially snippet ones) which do the same thing (possibly using globpath(), but e.g. ultisnips iterates over &runtimepath). So plugins which contain configuration for such plugins (e.g. plugins with snippet collections) cannot be installed the new way without being useless. I also saw ultisnips using globpath(&runtimepath, 'syntax/*.vim') for whatever reason. This code breaks. --- Thus I would say that this idea is bad because it will break plugin managers and it will break plugins using globpath(&runtimepath) or similar techniques. It is also pointless: a big number of entries in &runtimepath does not slow down Vim much compared to the IO from iterating over that much directories (which will not change just because you use another method for getting a list of directories to iterate over), so the only benefit is that user can check that something is contained in his &runtimepath easier. > > Best regards, > Tony. >> >>> >>> A disadvantage is that startup will be a bit slower, since Vim has to >>> read more directories to find all the files. That's a small price to >>> pay. Especially if we only do this for some plugins, not all the >>> distributed ones. That implies that what's under $VIMRUNTIME/bundles is >>> found first. >>> >>> -- >>> Press any key to continue, press any other key to quit. >>> >>> /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ >>> /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ >>> \\\ an exciting new programming language -- http://www.Zimbu.org /// >>> \\\ help me help AIDS victims -- http://ICCF-Holland.org /// >>> > > -- > -- > 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
