Nikolay Pavlov wrote:
> 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.
Do I understand that the problem is that the name "bundles" is already
used? We could just use another name. It's new so it doesn't really
matter.
> > 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 would assume in most cases installed plugins are active. If you do
need to disable one for whatever reason, it should be easy to use a
global variable. Just need a naming scheme. E.g. "disable_plugin_foo".
> 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.
Why not use <sfile> ? Iterating over runtimepath seems like a last
resort.
> I also saw ultisnips using globpath(&runtimepath, 'syntax/*.vim') for
> whatever reason. This code breaks.
I think it's fairly unusual for a plugin to find all other plugin stuff.
Where that is really needed a solution can be found. In the example,
also use globpath(&runtimepath, 'bundles/*/syntax/*.vim').
> 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.
I disagree. If you are using a plugin manager it won't change anything.
Well, the plugin manager may take advantage of the new feature and a few
details may need to be updated. If you don't use a plugin manager then
this feature is a nice way of organising plugins.
--
Some of the well known MS-Windows errors:
EMULTI Multitasking attempted, system confused
EKEYBOARD Keyboard locked, try getting out of this one!
EXPLAIN Unexplained error, please tell us what happened
EFUTURE Reserved for our future mistakes
/// 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.
