Poll: What's good about plugin managers?

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Poll: What's good about plugin managers?

Bram Moolenaar

At some point Vim started supporting plugins.  At that time it was fine
to add a plugin manually, it was a one-time thing.  But now that there
are so many plugins and they get updated often, manually updating
plugins has become tedious.

I am wondering what Vim users like about plugin managers.
Is there one that works best, that everybody should use?
Are there still features that no existing plugin manager offers?

Vundle appears to be popular, someone mentioned it's better than
Pathogen.  So nobody is using Pathogen?

But then there is also NeoBundle.  But not everybody has git installed
and it depends on that.

And there also is vim-addon-manager. And Vimball.

Is it fine to have a choice of plugin managers, or is this causing a
headache (for users and/or for plugin writers).  If yes, then we should
pick one plugin manager and retire the others.

--
Bad programs can be written in any language.

 /// Bram Moolenaar -- [hidden email] -- 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_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

Michael Hernandez-2

> On Mar 23, 2014, at 11:34 AM, Bram Moolenaar <[hidden email]> wrote:
>
>
> At some point Vim started supporting plugins.  At that time it was fine
> to add a plugin manually, it was a one-time thing.  But now that there
> are so many plugins and they get updated often, manually updating
> plugins has become tedious.
>
> I am wondering what Vim users like about plugin managers.
> Is there one that works best, that everybody should use?
> Are there still features that no existing plugin manager offers?
>
> Vundle appears to be popular, someone mentioned it's better than
> Pathogen.  So nobody is using Pathogen?
>
> But then there is also NeoBundle.  But not everybody has git installed
> and it depends on that.
>
> And there also is vim-addon-manager. And Vimball.
>
> Is it fine to have a choice of plugin managers, or is this causing a
> headache (for users and/or for plugin writers).  If yes, then we should
> pick one plugin manager and retire the others.
>

I think it's fine to have a choice of manager. I was using Vundle because it was so easy but I've switched to NeoBundle because it is simple like Vundle, but can handle automation of post-install tasks such as compiling a auxiliary component for you.

--Mike H

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

Ellis Kenyo
I agree with this. It comes down to freedom of choice really. I see no
reason to continue Pathogen, it too depends on git and NeoBundle does
such a better job. The others have their own places though.
On 23/03/14 16:15, Michael Hernandez wrote:

>> On Mar 23, 2014, at 11:34 AM, Bram Moolenaar <[hidden email]> wrote:
>>
>>
>> At some point Vim started supporting plugins.  At that time it was fine
>> to add a plugin manually, it was a one-time thing.  But now that there
>> are so many plugins and they get updated often, manually updating
>> plugins has become tedious.
>>
>> I am wondering what Vim users like about plugin managers.
>> Is there one that works best, that everybody should use?
>> Are there still features that no existing plugin manager offers?
>>
>> Vundle appears to be popular, someone mentioned it's better than
>> Pathogen.  So nobody is using Pathogen?
>>
>> But then there is also NeoBundle.  But not everybody has git installed
>> and it depends on that.
>>
>> And there also is vim-addon-manager. And Vimball.
>>
>> Is it fine to have a choice of plugin managers, or is this causing a
>> headache (for users and/or for plugin writers).  If yes, then we should
>> pick one plugin manager and retire the others.
>>
> I think it's fine to have a choice of manager. I was using Vundle because it was so easy but I've switched to NeoBundle because it is simple like Vundle, but can handle automation of post-install tasks such as compiling a auxiliary component for you.
>
> --Mike H
>

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

ping song
I think it's best to have a vim built-in standardized/official plugin manager.
for an ordinary user it's often confusing to choose between many options - so better to have an official one (better have most features centralized/integrated) to start with ...


On Sun, Mar 23, 2014 at 12:47 PM, ed jones <[hidden email]> wrote:
I agree with this. It comes down to freedom of choice really. I see no reason to continue Pathogen, it too depends on git and NeoBundle does such a better job. The others have their own places though.

On 23/03/14 16:15, Michael Hernandez wrote:
On Mar 23, 2014, at 11:34 AM, Bram Moolenaar <[hidden email]> wrote:


At some point Vim started supporting plugins.  At that time it was fine
to add a plugin manually, it was a one-time thing.  But now that there
are so many plugins and they get updated often, manually updating
plugins has become tedious.

I am wondering what Vim users like about plugin managers.
Is there one that works best, that everybody should use?
Are there still features that no existing plugin manager offers?

Vundle appears to be popular, someone mentioned it's better than
Pathogen.  So nobody is using Pathogen?

But then there is also NeoBundle.  But not everybody has git installed
and it depends on that.

And there also is vim-addon-manager. And Vimball.

Is it fine to have a choice of plugin managers, or is this causing a
headache (for users and/or for plugin writers).  If yes, then we should
pick one plugin manager and retire the others.

I think it's fine to have a choice of manager. I was using Vundle because it was so easy but I've switched to NeoBundle because it is simple like Vundle, but can handle automation of post-install tasks such as compiling a auxiliary component for you.

--Mike H


--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

Chris Lott
In reply to this post by Ellis Kenyo
On Sun, Mar 23, 2014 at 8:47 AM, ed jones <[hidden email]> wrote:
> I see no reason to continue Pathogen, it too depends on git


How so?

c
--
Chris Lott <[hidden email]>

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

Ellis Kenyo
Indirectly, I guess. There's still no reason to continue it.
On 23/03/14 17:04, Chris Lott wrote:
> On Sun, Mar 23, 2014 at 8:47 AM, ed jones <[hidden email]> wrote:
>> I see no reason to continue Pathogen, it too depends on git
>
> How so?
>
> c
> --
> Chris Lott <[hidden email]>
>

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

lith
In reply to this post by Bram Moolenaar
> Is it fine to have a choice of plugin managers, or is this causing a
> headache (for users and/or for plugin writers).  If yes, then we should
> pick one plugin manager and retire the others.

I'm glad you picked this topic up.

I personally use simple shell scripts to keep the git repos up to date. I don't think having the plugin manager built-in is a necessity although it would make things easier for newcomers, I guess.

IMHO almost any choice is better than the current situation.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

LCD 47
In reply to this post by Ellis Kenyo
On 23 March 2014, ed jones <[hidden email]> wrote:
> On 23/03/14 17:04, Chris Lott wrote:
> >On Sun, Mar 23, 2014 at 8:47 AM, ed jones <[hidden email]> wrote:
> >>I see no reason to continue Pathogen, it too depends on git
> >
> >How so?
>
> Indirectly, I guess. There's still no reason to continue it.

    You just pointed out a reason: it solves *one* problem, namely it
integrates plugins with Vim, and it does that perfectly.  It doesn't try
to *also* solve the (unrelated) problems of finding plugins, fetching
them over network, keeping them up to date, resolving dependencies,
compiling binaries, or anything else.  It does one thing, and then it
gets out of your way.  Some people prefer to do things their way, others
prefer one-button solutions.

    /lcd

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

A. S. Budden
In reply to this post by Bram Moolenaar
On 23 March 2014 15:34, Bram Moolenaar <[hidden email]> wrote:

>
> At some point Vim started supporting plugins.  At that time it was fine
> to add a plugin manually, it was a one-time thing.  But now that there
> are so many plugins and they get updated often, manually updating
> plugins has become tedious.
>
> I am wondering what Vim users like about plugin managers.
> Is there one that works best, that everybody should use?
> Are there still features that no existing plugin manager offers?
>
> Vundle appears to be popular, someone mentioned it's better than
> Pathogen.  So nobody is using Pathogen?
>
> But then there is also NeoBundle.  But not everybody has git installed
> and it depends on that.
>
> And there also is vim-addon-manager. And Vimball.
>
> Is it fine to have a choice of plugin managers, or is this causing a
> headache (for users and/or for plugin writers).  If yes, then we should
> pick one plugin manager and retire the others.

Personally, I think it's fine to have a choice.

I use pathogen in combination with my own shell script that I wrote a
long time ago - I like the look of Vundle, but it only supports git so
is no good for plugins that are maintained in mercurial or bazaar.  I
know there's the mirror of published ones, but sometimes it's good to
be able to use the latest development versions.  I wouldn't mind the
idea of a 'standard' vim plugin manager, but if it locked users in to
git I'd want there to be some way to turn it off and go ones own way.

Al

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

Nikolay Aleksandrovich Pavlov
In reply to this post by Bram Moolenaar
On Sunday, March 23, 2014 7:34:19 PM UTC+4, Bram Moolenaar wrote:

> At some point Vim started supporting plugins.  At that time it was fine
> to add a plugin manually, it was a one-time thing.  But now that there
> are so many plugins and they get updated often, manually updating
> plugins has become tedious.
>
> I am wondering what Vim users like about plugin managers.
> Is there one that works best, that everybody should use?
> Are there still features that no existing plugin manager offers?
>
> Vundle appears to be popular, someone mentioned it's better than
> Pathogen.  So nobody is using Pathogen?
>
> But then there is also NeoBundle.  But not everybody has git installed
> and it depends on that.
>
> And there also is vim-addon-manager. And Vimball.
>
> Is it fine to have a choice of plugin managers, or is this causing a
> headache (for users and/or for plugin writers).  If yes, then we should
> pick one plugin manager and retire the others.

You are mixing entities here. Vundle, NeoBundle and vim-addon-manager are plugin
managers. I.e. they are able to take tasks of installing, updating, configuring
and removing plugins. (List is from wikipedia definition of a package manager.)

Pathogen cannot install, update or configure anything. It is not a plugin
manager. It allows runtimepath manipulations and has some code to open files in
installed plugins, but that’s all. If you want a plugin manager you should
retire pathogen from discussion.

Vimball is missing update and configure features from the list. It is just an
archiving tool with unexpected functionality of recording installed files and
removing them by one command. Latter functionality is incomplete: it will leave
empty directories. So I would retire it from discussion as well. But definitely
not retire completely.

> But then there is also NeoBundle.  But not everybody has git installed
> and it depends on that.

It is Vundle which requires git and only git. I do not know the current status,
but NeoBundle did have support for other VCS systems. Author also was doing some
work on integrating it with https://bitbucket.org/vimcommunity/vim-pi (which is
plugin index), though halted because I switched my efforts on NeoVim project as
it seems to be more urgent. Do not know what is the current state of this
support and whether you can use NeoBundle without git.

> I am wondering what Vim users like about plugin managers.
> Is there one that works best, that everybody should use?
> Are there still features that no existing plugin manager offers?

If you take package manager from almost any other project (e.g. pip (python),
luarocks (lua), gem (ruby), etc; not saying about package managers that are used
in linux distributions) you will see that current plugin managers lack

1. Support for installing exact versions of the plugins.
2. Support for dependencies with accepted version range.
3. Support for installing system-wide or in user directory. VAM has some sort of
it, but to use it you must first configure the target directory and only then
install it there. Nothing like `:InstallAddons --local` (with default
system-wide) or `:InstallAddons --system` (with default user-local).
4. Support for things like virtual environments.
5. (Only applicable for PM already managed in the topic, some do support it.)
   Installing software not in a separate folders.

You may find comparison table in
http://vimpluginloader.sourceforge.net/doc/vim-addon-manager-additional-documentation.txt.html#VAM-comparison.
Beware: it may be outdated though.

After reading this comparison you will see though that NeoBundle is the best
plugin manager out there (the only minus “Dependencies are specified in the
vimrc, not in the installed plugin.” is going to be erased once vim-pi support
will be ready). Note that the author of comparison (me) did not actually used
NeoBundle, only read its help. Its competitor though is not appropriate for
being Vim official plugin manager in the current stage due to its development
cycle (@MarcWeber uses “experimental programming” and no releases. I did not
like the idea, but I am not the author.). I hope he will appear here and comment
the situation: it would be good if a plugin manager I am a co-author of will
appear in main tree.

--------------------------------------------------------------------------------

One thing about the topic: do you really want a *poll* **right now**? I think it
is best to formulate requirements to the plugin manager, collect the responses
of the authors of existing plugin managers and then decide how to go further on.
Most likely after formulating the requirements most of the variants will be
automatically retired and other variants will be comparable enough to actually
launch a poll.

A list of things I would expect from a plugin manager:

1. Installing plugins in a FHS-compatible fashion (i.e. in
   /usr/share/vimfiles/…). Target directory must be configurable. Reason: to
   respect package maintainers from various distributions and do not make them
   duplicate installing functionality on their end.
2. Outputting dependency list in a standard way. Reason: to make tools like
   `g-cpan` (automatically generates Gentoo ebuilds for perl packages) able to
   exist. It again prevents duplicating work on a distribution maintainers side.
3. Exact versions installation and dependencies with versions. Reason: new
   versions of plugins may be incompatible with dependent plugins, or may have
   some functionality removed. Low priority, because usually there are no
   compatibility problems if you just use latest versions of all plugins.
4. Ability to recognize presence of plugins that were not installed by itself or
   some index of installed packages with an official API functions to manipulate
   it. Reason: make it able to mix system-wide installed plugins and user-local
   installations, assuming system-wide will be installed by system plugin
   manager; it also enables distribution maintainers to just rely on plugin
   manager to install required plugin.
5. Ability to ignore package dependencies. Reason: overlaps with 4: enable
   distribution maintainer to just rely on plugin manager and on the fact that
   it under no circumstances will fetch unwanted dependency so it won’t leak in
   the binary package.

---

6. Ability to install plugins to a separate directory. Reason: for user it is
   easy to find which files relate to which plugin.
7. Ability to update plugins without changing installation directory, ignoring
   system-wide (if invoked from regular user) or user-local (if invoked from
   root) installation updates. Reason: centralized updates are convenient.
8. Ability to track and preserve user changes to installed plugins or ability to
   halt updating process if files were modified. Reason: some plugins expect
   users to configure them in the same directory they are located in (example:
   snipmate) or are simply not configurable.
9. Ability to run certain code on plugin installation and update. Possibly also
   during uninstallation. Reason: some plugins require building of their C code,
   some simply have incorrect directory structure so that it is needed to copy
   files.
10. Ability to work with all kinds of sources present on www.vim.org. Reason:
    you cannot really expect plugin authors to massively change archive types.
11. Ability to work with VCS sources. Reason: some plugins are available only
    from github, some have useful features that were not released yet.
12. Ability to remove plugins. Reason: centralized removal is convenient as
    well. Low priority.
13. Ability to list and remove unused plugins. Reason: it is just convenient.
    Low priority.

---

14. Ability to specify location where to download sources and where to take
    downloaded sources from. Reason: if user has spoiled installation make it
    easy and fast to reinstall, if user has no Internet connection make it
    possible to install. Low priority.
15. Ability to list URLs to download (possibly in a shell script). Reason: if
    user has no Internet connection make it still some sort of usable. Low
    priority.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

Mun-4
In reply to this post by Bram Moolenaar
Hi Bram, et al.,

On Sun, Mar 23, 2014 at 08:34 AM PDT, Bram Moolenaar wrote:
BM>
BM> At some point Vim started supporting plugins.  At that time it was fine
BM> to add a plugin manually, it was a one-time thing.  But now that there
BM> are so many plugins and they get updated often, manually updating
BM> plugins has become tedious.
BM>
BM> I am wondering what Vim users like about plugin managers.
BM> Is there one that works best, that everybody should use?
BM> Are there still features that no existing plugin manager offers?
BM>
BM> Vundle appears to be popular, someone mentioned it's better than
BM> Pathogen.  So nobody is using Pathogen?
BM>
BM> But then there is also NeoBundle.  But not everybody has git installed
BM> and it depends on that.
BM>
BM> And there also is vim-addon-manager. And Vimball.
BM>
BM> Is it fine to have a choice of plugin managers, or is this causing a
BM> headache (for users and/or for plugin writers).  If yes, then we should
BM> pick one plugin manager and retire the others.

I whole-heartedly agree that maintaining a plethora of plugins has become
quite tedious.  Of the plugin managers listed above, Vimball is the only
one I use regularly.  Although, I often think I need to take the time
for a more complete solution.

If Vim came with a plugin manager (implying it has met with Bram's
approval) that could be set-up/configured easily and which could
automatically keep my plugins updated, I'd be all over it.  Kind of like
the Package Updater (pup) on Linux.

I'm glad this is being recognized as an issue and that you are at least
entertaining possible solutions.

Regards,

--
Mun

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

Israel Chauca Fuentes
In reply to this post by Bram Moolenaar
On 3/23/14, 11:34 AM, Bram Moolenaar wrote:
>
> At some point Vim started supporting plugins.  At that time it was fine
> to add a plugin manually, it was a one-time thing.  But now that there
> are so many plugins and they get updated often, manually updating
> plugins has become tedious.
>
> I am wondering what Vim users like about plugin managers.

I use Pathogen for the following reasons:
- Allows to have every plugin segregated in its own directory.
- It's posible to have more than one "bundle" dir. At least in my clone.
- Leaves the plugin management up to the user. It doesn't
install/remove/update plugins.
- Individual plugins can be temporarily disabled by filtering them out
of the runtimepath at start up.
- The configuration is dead simple.

> Is there one that works best, that everybody should use?

Since we don't have a canonical source for plugins, I doubt that any
plugin manager will be able to handle the current and future multitude
of sources and formats on which plugins are and will be available.

> Are there still features that no existing plugin manager offers?

I can think of only one "feature" that could make a plugin manager a
viable tool: to be a built-in feature of Vim (I'd prefer a solution in
VimL, but one in C would make me happy too) and use vim.org as the only
source for plugins.

> Vundle appears to be popular, someone mentioned it's better than
> Pathogen.  So nobody is using Pathogen?

Without being a plugin manager Pathogen is still a popular choice and,
given its simplicity, I doubt that that will change any time soon.

> But then there is also NeoBundle.  But not everybody has git installed
> and it depends on that.
>
> And there also is vim-addon-manager. And Vimball.
>
> Is it fine to have a choice of plugin managers, or is this causing a
> headache (for users and/or for plugin writers).  If yes, then we should
> pick one plugin manager and retire the others.

I think it's good to have choices, but I also think that having a
built-in plugin manager that uses a single source would be even better.
It would allow to concentrate the work on a single project, a simplest
project since it wouldn't have to handle multiple sources and formats.
It could even provide a base for external plugins to provide additional
features, as is to be expected of every aspect of vim.

Cheers!
Israel

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

Nikolay Aleksandrovich Pavlov


On Mar 24, 2014 3:50 AM, "Israel Chauca" <[hidden email]> wrote:
>
> On 3/23/14, 11:34 AM, Bram Moolenaar wrote:
>>
>>
>> At some point Vim started supporting plugins.  At that time it was fine
>> to add a plugin manually, it was a one-time thing.  But now that there
>> are so many plugins and they get updated often, manually updating
>> plugins has become tedious.
>>
>> I am wondering what Vim users like about plugin managers.
>
>
> I use Pathogen for the following reasons:
> - Allows to have every plugin segregated in its own directory.
> - It's posible to have more than one "bundle" dir. At least in my clone.
> - Leaves the plugin management up to the user. It doesn't install/remove/update plugins.
> - Individual plugins can be temporarily disabled by filtering them out of the runtimepath at start up.
> - The configuration is dead simple.
>
>
>> Is there one that works best, that everybody should use?
>
>
> Since we don't have a canonical source for plugins, I doubt that any plugin manager will be able to handle the current and future multitude of sources and formats on which plugins are and will be available.

VAM is handling this matter rather good. There is no problem in handling 99% of plugins since they are either hosted on github or on www.vim.org in though wide, but limited variety of archive formats.

You can also extend VAM to use any function to install plugin thus adding support for any VCS that is not yet supported.

>> Are there still features that no existing plugin manager offers?
>
>
> I can think of only one "feature" that could make a plugin manager a viable tool: to be a built-in feature of Vim (I'd prefer a solution in VimL, but one in C would make me happy too) and use vim.org as the only source for plugins.

www.vim.org lacks very huge number of features. Look at pypi.python.org: it is an example of a good package index. At least www.vim.org must have an API. It would also be handy to specify location of development version, things like maturity status and license.

And you are mistaking if you think there is no built-in plugin manager: there is GLVS that uses www.vim.org as source. Have you heard of anybody using it? VCS support nowadays is an ultimate requirement, www.vim.org may be the only source of information about plugins (which is a very bad idea because it does not even have HTTPS), but using VCS during installation step should be required.

>
>
>> Vundle appears to be popular, someone mentioned it's better than
>> Pathogen.  So nobody is using Pathogen?
>
>
> Without being a plugin manager Pathogen is still a popular choice and, given its simplicity, I doubt that that will change any time soon.
>
>
>> But then there is also NeoBundle.  But not everybody has git installed
>> and it depends on that.
>>
>> And there also is vim-addon-manager. And Vimball.
>>
>> Is it fine to have a choice of plugin managers, or is this causing a
>> headache (for users and/or for plugin writers).  If yes, then we should
>> pick one plugin manager and retire the others.
>
>
> I think it's good to have choices, but I also think that having a built-in plugin manager that uses a single source would be even better. It would allow to concentrate the work on a single project, a simplest project since it wouldn't have to handle multiple sources and formats. It could even provide a base for external plugins to provide additional features, as is to be expected of every aspect of vim.

Bad idea. You cannot live in real word thinking that there may be the only format which will be adopted by everybody, especially by plugin authors that are effectively dead (no activity on www.vim.org, may be as well dead IRL).

>
> Cheers!
> Israel
>
>
> --
> --
> You received this message from the "vim_use" 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_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

LCD 47
In reply to this post by Nikolay Aleksandrovich Pavlov
On 23 March 2014, ZyX <[hidden email]> wrote:
[...]

> A list of things I would expect from a plugin manager:
>
> 1. Installing plugins in a FHS-compatible fashion (i.e. in
>    /usr/share/vimfiles/…). Target directory must be configurable. Reason: to
>    respect package maintainers from various distributions and do not make them
>    duplicate installing functionality on their end.
> 2. Outputting dependency list in a standard way. Reason: to make tools like
>    `g-cpan` (automatically generates Gentoo ebuilds for perl packages) able to
>    exist. It again prevents duplicating work on a distribution maintainers side.
> 3. Exact versions installation and dependencies with versions. Reason: new
>    versions of plugins may be incompatible with dependent plugins, or may have
>    some functionality removed.

    Three other related features might come in handy here:

- a list of conflicting plugins, with versions
- a list of conflicting settings in other plugins
- a list of required Vim features and / or version restrictions.

>    Low priority, because usually there are no compatibility problems
>    if you just use latest versions of all plugins.

    Sadly, this point goes down the drain as soon as the user locks
a plugin to a certain version (presumably because newer ones break
something).  No, this is likely to turn out to be a crucial feature
(and probably also impossible to get right).

> 4. Ability to recognize presence of plugins that were not installed by itself or
>    some index of installed packages with an official API functions to manipulate
>    it. Reason: make it able to mix system-wide installed plugins and user-local
>    installations, assuming system-wide will be installed by system plugin
>    manager; it also enables distribution maintainers to just rely on plugin
>    manager to install required plugin.
> 5. Ability to ignore package dependencies. Reason: overlaps with 4: enable
>    distribution maintainer to just rely on plugin manager and on the fact that
>    it under no circumstances will fetch unwanted dependency so it won’t leak in
>    the binary package.
>
> ---
>
> 6. Ability to install plugins to a separate directory. Reason: for user it is
>    easy to find which files relate to which plugin.
> 7. Ability to update plugins without changing installation directory, ignoring
>    system-wide (if invoked from regular user) or user-local (if invoked from
>    root) installation updates. Reason: centralized updates are convenient.
> 8. Ability to track and preserve user changes to installed plugins or ability to
>    halt updating process if files were modified. Reason: some plugins expect
>    users to configure them in the same directory they are located in (example:
>    snipmate) or are simply not configurable.

    Not really feasible if the source of the plugin is not in a VCS of
some sort.

> 9. Ability to run certain code on plugin installation and update. Possibly also
>    during uninstallation. Reason: some plugins require building of their C code,
>    some simply have incorrect directory structure so that it is needed to copy
>    files.
> 10. Ability to work with all kinds of sources present on www.vim.org. Reason:
>     you cannot really expect plugin authors to massively change archive types.

    Well, if you want to get rid of the existing mess of formats, now
would be the right time (and probably an opportunity we might never come
to again in the foreseeable future).

> 11. Ability to work with VCS sources. Reason: some plugins are available only
>     from github, some have useful features that were not released yet.
> 12. Ability to remove plugins. Reason: centralized removal is convenient as
>     well. Low priority.
> 13. Ability to list and remove unused plugins. Reason: it is just convenient.
>     Low priority.

    That would imply keeping stats about when each plugin is actually
used.  A complicated, expensive, and tricky task, for very little gain.

> ---
>
> 14. Ability to specify location where to download sources and where to take
>     downloaded sources from. Reason: if user has spoiled installation make it
>     easy and fast to reinstall, if user has no Internet connection make it
>     possible to install. Low priority.
> 15. Ability to list URLs to download (possibly in a shell script). Reason: if
>     user has no Internet connection make it still some sort of usable. Low
>     priority.

    A very well thought-out list.

    /lcd

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

MarcWeber
In reply to this post by Nikolay Aleksandrovich Pavlov
To sum up:

If people would have known about this page this thread would have been
shorter:
http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html
(just add your own comments if you think the article is incomplete, you can
edit without registering)

I'd like to remind that I posted some time ago about whether anybody would mind
me making users work (such as such wiki) more visible, no replies. We do not only
have a problem about "plugin managers", its a problem about managing community,
about making vim.sf.net the best source of knowledge (collaboratively) - the
community failed on this for 30 years. vim.sf.net is outdated (in some regards).

This lead to eg Shougo potentially 'starting NeoBundle' missing VAM - thus one
reason why we have 3 to 4 popular plugin managers now. Anyway NeoBundle
implements "parallel installing" - something I never had time for to implement because
it adds tons of issues which could go wrong (IMHO).

I agree on
- diversity is nice
- the more the merrier

but there is also one important resource in life: your time.
The more the merrier the more time you'll need to evaluate, throw away and try
something else. We as community should try to serve the user.

The management of the community fails - which is why I'm that glad that the
experiment "NeoVim" is taking place (hoping that such issues get fixed there).
And that experiment makes me stop working on any plugin solution at the moment
till its more clear how things turn out.

People say "vundle is easy".
The truth is: Many patches got bitrotted and where never merged. Some weeks ago
I reviewed "all" issues - and even found trivial bugs such as "on windows it
should be vimfiles" to to three times reported. Collaboration doesn't make
sense / because if I contributed to Vundle I'd turn it into VAM. I offered
using VAM's engine, this idea was disregarded by gmaric (which is fine).

Details here (a lot of such issues got closed then):
https://github.com/gmarik/Vundle.vim/issues/241

https://github.com/gmarik/Vundle.vim/issues/388 (why isn't vundle declarative ?)
NeoBundle "fixed" this by adding a command meaning "make sure things are there
and can be activated"

Because Vundle is not declarative Vim's behaviour depends on whether you
installed a plugin or not. If a plugin is missing Vim will startup silently.
Whether this is what you want or not depends on you.

I accept that there are many managers - I'd like to help people find the right
tool. Things which got suggested on mailinglist: use github search only.
This may lead to users finding outdated plugins which got starred in the past
(eg Sanders snipmate) which were taken over after 1-2 years of no reply by the
maintainer and is now "maintained" by 2-3 people from the community.

Whatever solution exists - it should not force anything on the user, but guide
him. This is what vim-pi is about. vim-pi tries to be the one missing source of plugins:
https://bitbucket.org/vimcommunity/vim-pi and tell people if a plugin is
outdated for any reasons.

Anyway situation is as is - which is why I at least thought we could try to
provide a common interface so that at least install instructions could be shared
https://bitbucket.org/vimcommunity/vim-pi/issue/91/common-interface-for-most-plugin-managers

Nobody really tried to join. The idea was that people can have a
  :InstallPlugin name {options}
command for their .vimrc.

Now that NeoBundle is being worked on situation got more complex, more
investment doesn't make sense.

Let me reply to some more random comments:

@ping song
  > plugin manager build into Vim / VimL only

  Vim is "retarded" in the sense that its backward compatible (its a feature, too !).
 
  However plugins and maintainers evolve faster than people are updating VIMRUNTIME
  (The experiment splititng VIMRUNTIME off would be fun, too).

  But for VAM I would have been against making it official always because I
  wanted to allow updating it.

  Looking at history, which package manager should have been default?
  Again try to read up about a rough sketch of the history here:
  http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html

  pathogen, VAM, Vundle, NeoBundle - which one?
  There is a "official plugin manager" called 'vimball' and GetLatestVimScripts

  For this reason I feel a manager should not be official - unless there is a
  clear winner for clear reasons. Vundle has many users - but I don't think its
  the best solution because its not declarative. (my view)

But there are more issues: How to install plugins on Windows - eg installig git
is a pain (kind of). http://vam.mawercer.de/ is one solution to just get the
code by making my v-server fetch the plugins. Using ".zip" dowloading would be
another solution (which VAM actually does implement). But then you still need
7zip or unzip or such (again VAM tries hard about just getting it right).
unzip/git like tools could be provided by "plugins" which can be installed
or by cygwin or msys like environments on Windows. There was not enough
interest to make me or ZyX spend more time on this Windows topic.

Also there are hard/soft dependencies. hard (required), soft:optional.
How to encode this? Right now I think soft dependencies should be installed by
the user explicitly.

VAM introduced "addon-info.json" - a not very well defined format to declare
dependencies. (without knowing what is really useful upfront it looked sensible
to allow format people can add their own keys to).


How important is "version lock". For VAM in the past I thought that just using
latest versions is good enough - and reduces overall dev time - because there
is only one combination of plugins to take care of. We've prepared allowing
passing git hashes or such - but didn't finish the checkout implementation
(lack of interest) - doing so would be trivial.
For Vundle there have been PRs for years (see link above) which never got
merged, NeoBundle checkout specific versions.

The most important question is: How perfect do we want to be ?

@Israel Chauca
  VAM does not install plugin if it already exists, thus you can put anything
  into vim-addons/foo and make VAM behave like pathogen by asking it to activate
  foo. If it happens to be a git repository you'll be able to update it.

  Thus simulating Pathogen by VAM is trivial. VAM also has (unfinished) Vundle
  emulation.

  - Individual plugins can be temporarily disabled by filtering them out
  of the runtimepath at start up.

  Why take the burden to filter the runtimepath?

  In Vam you just don't activate them. EG

  " VAMActivate this-plugin

  because the line is commented everything will work as expected.
  For Pathogen people have code in their .vimrc to recreate helptags
  always because Pathogen does'nt know when a plugin got updated.
  Many small reasons to think about whether VAM/NeoBundle would
  serve the user better. (my view)

  > canonical source for plugins,
  vim-pi tries to be one
  And no, vim-scripts is not an option because it cannot disambiguate plugins
  having same name but different ids. Bug has been filed but never fixed long
  time ago.


Last but not least I don't want everybody to adopt VAM or NeoBundle. I want to
make it easier for users to find their own solution by telling them about
differences (which is why I started vim-wiki - everybody can edit it on disk,
its just a git repository). I've sent an email some time ago about making such
"wikis" more visible, not many replies. So in the end I got depressed.

The key is managing the community better / and collaborating on the important
things. Right now this means at least watch NeoVim eventually.

Sorry that there is no easy answer to this topic.

Marc Weber

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

Nikolay Aleksandrovich Pavlov
In reply to this post by LCD 47


On Mar 24, 2014 11:08 AM, "LCD 47" <[hidden email]> wrote:
>
> On 23 March 2014, ZyX <[hidden email]> wrote:
> [...]
> > A list of things I would expect from a plugin manager:
> >
> > 1. Installing plugins in a FHS-compatible fashion (i.e. in
> >    /usr/share/vimfiles/…). Target directory must be configurable. Reason: to
> >    respect package maintainers from various distributions and do not make them
> >    duplicate installing functionality on their end.
> > 2. Outputting dependency list in a standard way. Reason: to make tools like
> >    `g-cpan` (automatically generates Gentoo ebuilds for perl packages) able to
> >    exist. It again prevents duplicating work on a distribution maintainers side.
> > 3. Exact versions installation and dependencies with versions. Reason: new
> >    versions of plugins may be incompatible with dependent plugins, or may have
> >    some functionality removed.
>
>     Three other related features might come in handy here:
>
> - a list of conflicting plugins, with versions
> - a list of conflicting settings in other plugins
> - a list of required Vim features and / or version restrictions.
>
> >    Low priority, because usually there are no compatibility problems
> >    if you just use latest versions of all plugins.
>
>     Sadly, this point goes down the drain as soon as the user locks
> a plugin to a certain version (presumably because newer ones break
> something).  No, this is likely to turn out to be a crucial feature
> (and probably also impossible to get right).
>
> > 4. Ability to recognize presence of plugins that were not installed by itself or
> >    some index of installed packages with an official API functions to manipulate
> >    it. Reason: make it able to mix system-wide installed plugins and user-local
> >    installations, assuming system-wide will be installed by system plugin
> >    manager; it also enables distribution maintainers to just rely on plugin
> >    manager to install required plugin.
> > 5. Ability to ignore package dependencies. Reason: overlaps with 4: enable
> >    distribution maintainer to just rely on plugin manager and on the fact that
> >    it under no circumstances will fetch unwanted dependency so it won’t leak in
> >    the binary package.
> >
> > ---
> >
> > 6. Ability to install plugins to a separate directory. Reason: for user it is
> >    easy to find which files relate to which plugin.
> > 7. Ability to update plugins without changing installation directory, ignoring
> >    system-wide (if invoked from regular user) or user-local (if invoked from
> >    root) installation updates. Reason: centralized updates are convenient.
> > 8. Ability to track and preserve user changes to installed plugins or ability to
> >    halt updating process if files were modified. Reason: some plugins expect
> >    users to configure them in the same directory they are located in (example:
> >    snipmate) or are simply not configurable.
>
>     Not really feasible if the source of the plugin is not in a VCS of
> some sort.

VAM has working implementation. It is required to hold original archive though. VAM relies on VCS if plugin uses VCS though.

>
> > 9. Ability to run certain code on plugin installation and update. Possibly also
> >    during uninstallation. Reason: some plugins require building of their C code,
> >    some simply have incorrect directory structure so that it is needed to copy
> >    files.
> > 10. Ability to work with all kinds of sources present on www.vim.org. Reason:
> >     you cannot really expect plugin authors to massively change archive types.
>
>     Well, if you want to get rid of the existing mess of formats, now
> would be the right time (and probably an opportunity we might never come
> to again in the foreseeable future).

What for? Archive formats support is not much of a burden.

>
> > 11. Ability to work with VCS sources. Reason: some plugins are available only
> >     from github, some have useful features that were not released yet.
> > 12. Ability to remove plugins. Reason: centralized removal is convenient as
> >     well. Low priority.
> > 13. Ability to list and remove unused plugins. Reason: it is just convenient.
> >     Low priority.
>
>     That would imply keeping stats about when each plugin is actually
> used.  A complicated, expensive, and tricky task, for very little gain.

Simplest implementation is just taking a list of currently active plugins and remove everything but them. VAM/Vundle/NeoBundle have everything what is necessary to perform such a task. It is not so easy for FHS-based installations, but it is easy to implement if you just do not provide this functionality for this task.

And check out :scriptnames. Recording its output at VimLeave makes such functionality rather easy.

>
> > ---
> >
> > 14. Ability to specify location where to download sources and where to take
> >     downloaded sources from. Reason: if user has spoiled installation make it
> >     easy and fast to reinstall, if user has no Internet connection make it
> >     possible to install. Low priority.
> > 15. Ability to list URLs to download (possibly in a shell script). Reason: if
> >     user has no Internet connection make it still some sort of usable. Low
> >     priority.
>
>     A very well thought-out list.
>
>     /lcd
>
> --
> --
> You received this message from the "vim_use" 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_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

Erik Christiansen
In reply to this post by MarcWeber
On 24.03.14 10:17, Marc Weber wrote:
> Anyway situation is as is - which is why I at least thought we could try to
> provide a common interface so that at least install instructions could be shared
> https://bitbucket.org/vimcommunity/vim-pi/issue/91/common-interface-for-most-plugin-managers

That is the conclusion which was forming in my mind as I read the thread.
If Vim provides one documented user interface, and one API for plugin
managers, defining _what_ features may be invoked, then neither users
nor Vim maintainers need be incommoded by any number of competing
managers with any number of approaches to _how_ it's done. The API would
provide for a "NAK - can't do that." response from a manager. And a help
entry would present a table of managers, listing the features provided
by each.

> Nobody really tried to join.

There are personalities which cannot collaborate to improve existing
infrastructure for the common good, but are compelled to use any pretext
to reinvent the wheel. On another list it was so essential to reimplement
the existing very good uP simulator, that it just _had_ to be redone in C++.
Result: neither is now maintained, AFAIR.

Admittedly, in youth we think we can do it all, after all there is time
enough, and energy to burn. It is only later that we realise that the
energy has been burned, and the time consumed, without adding anything
that hadn't been done already.

> The idea was that people can have a
>   :InstallPlugin name {options}
> command for their .vimrc.

And a

   :UsePluginManager name

as well?

Erik

--
The wonderful thing about standards is that there are so many of them.      
                                                        - Andy Tanenbaum

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

lith
In reply to this post by Bram Moolenaar
> Vundle appears to be popular

Regarding vundle: I'm no vundle user but I recently stumbled over this blog entry while googling for something else: http://gmarik.info/blog/2014/02/04/why-i-stopped-contributing-to-vundle

Given the commits list though, it seems vundle is still alive and kicking: https://github.com/gmarik/Vundle.vim/commits/master

It would be interesting if the authors of all those plugins would chime in and explain why they wrote X while Y already existed and what it does better or worse.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

Gary Johnson-4
In reply to this post by Nikolay Aleksandrovich Pavlov
On 2014-03-24, Nikolay Pavlov wrote:
>
> On Mar 24, 2014 11:08 AM, "LCD 47" wrote:
> >
> > On 23 March 2014, ZyX wrote:

> > > 13. Ability to list and remove unused plugins. Reason: it is just
> > >     convenient.
> > >     Low priority.
> >
> >     That would imply keeping stats about when each plugin is actually
> > used.  A complicated, expensive, and tricky task, for very little gain.
>
> Simplest implementation is just taking a list of currently active plugins and
> remove everything but them. VAM/Vundle/NeoBundle have everything what is
> necessary to perform such a task. It is not so easy for FHS-based
> installations, but it is easy to implement if you just do not provide this
> functionality for this task.

How do you know whether or not a plugin is "actually used"?

Regards,
Gary

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Poll: What's good about plugin managers?

Nikolay Aleksandrovich Pavlov


On Mar 24, 2014 10:19 PM, "Gary Johnson" <[hidden email]> wrote:
>
> On 2014-03-24, Nikolay Pavlov wrote:
> >
> > On Mar 24, 2014 11:08 AM, "LCD 47" wrote:
> > >
> > > On 23 March 2014, ZyX wrote:
>
> > > > 13. Ability to list and remove unused plugins. Reason: it is just
> > > >     convenient.
> > > >     Low priority.
> > >
> > >     That would imply keeping stats about when each plugin is actually
> > > used.  A complicated, expensive, and tricky task, for very little gain.
> >
> > Simplest implementation is just taking a list of currently active plugins and
> > remove everything but them. VAM/Vundle/NeoBundle have everything what is
> > necessary to perform such a task. It is not so easy for FHS-based
> > installations, but it is easy to implement if you just do not provide this
> > functionality for this task.
>
> How do you know whether or not a plugin is "actually used"?

Just how PM knows whether it needs to add certain path to &runtimepath or not.

>
> Regards,
> Gary
>
> --
> --
> You received this message from the "vim_use" 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_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
123