2016-02-09 16:28 GMT+03:00 Bram Moolenaar <[email protected]>:
>
> 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.
>
>> 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.
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.
>
> --
> 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.
