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.
>
> Yes. But this will not address other points.
>
> >
> >> > 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 *must not* use <sfile>. User configuration should be in
> ~/.vim/config. Or ~/.config/vim/config. Or whatever. But *not* in
> ~/.vim/bundles/translit3/config because it is in a separate repository
> that holds a clone of translit3 and config/ there contains default
> configuration. As a user I would not want to create translit3 fork
> just to hold my configuration.
>
> It is not “last resort”. It is *intentional*. Same for snippets:
> plugin that uses snippets, plugin that contains snippets and user
> snippets are separate things in different directories in &runtimepath,
> in different repositories.
Eh, what you are saying here is that it will just keep working, since
user's configuration files will be in 'runtimepath' just like before,
doesn't change.
I meant using <sfile> for the plugin to find other files that come with
it, so they should be in the same directory where the plugin .vim file
is.
> >> 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').
>
> This requires changes to existing code. Until this all plugins using
> something like this are broken.
Most syntax files will still be where they were, so I don't think there
is much that breaks.
> In any case this will make code more complex.
>
> Also needs easy way to test for the feature (like `has('bundles')`,
> `has('patch…')` is not readable (purpose of the code is not obvious
> from the code)) or they will be broken after.
>
> >
> >> 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.
>
> If I don’t I can have this be handled by pathogen. The only value that
> this feature in core really adds is that I can have nice &runtimepath
> and can omit installing pathogen. This is not worth the hassle: I have
> saw code iterating over &runtimepath in one way or the other
> (globpath() or direct iterations over split) in
>
> 1. All snippet plugins I have installed: UltiSnips, neosnippet,
> snipmate, xptemplate.
> 2. Plugins that allow to select something from a list: ku, unite,
> neoui, FuzzyFinder, Command-T.
> 3. Plugins which have plugins*: airline, neocomplcache,
> vim-powerline**, syntastic.
> 4. Some libraries: lh-vim-lib, vial.
> 5. Other: vim-latex (latex-suite), Threesome, tplugin, PreserveNoEOL,
> cuteErrorMarker, vimwiki, viewdoc, Transmit_FTP, VimLint.
>
> Total 24 plugins, 10% of what I have in ~/.vam and I do not have all
> existing plugins installed. Some of them are not maintained, but still
> usable AFAIK.
>
> * It is not necessary that these plugins iterate over &runtimepath
> *because* they have plugins.
> ** Deprecated old VimL-only plugin, still used by somebody, though
> people mostly switched to either airline or Python powerline.
We could add an option or command to add all directories found under the
new "bundles" directory to 'runtimepath', sounds like that will make it
work for backwards compatibility.
--
Some of the well known MS-Windows errors:
ETIME Wrong time, wait a little while
ECRASH Try again...
EDETECT Unable to detect errors
EOVER You lost! Play another game?
ENOCLUE Eh, what did you want?
/// 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.
