Excerpts from ZyX's message of Fri Jan 03 00:51:55 +0100 2014:
> > I meant for the web downloader, where does that come from? I assume always
> > from git.
> What web downloader?
vam.mawercer.de That basically runs VAM install on my v-server and zips
the result.
Marc Weber
--
--
You received t
Ben Fritz wrote:
>> You know about $http_proxy (or some other method of telling
>> the tool about your proxy server)?
>
> Nope, never heard of such a thing. But I actually never use
> git except for getting Vim plugins.
>
> At one point I could access Hg and git repositories just fine,
> but not SV
On Thursday, January 2, 2014 7:18:20 PM UTC-6, JohnBeckett wrote:
> Ben Fritz wrote:
>
> > Because my workplace's IT somehow blocks access to github and
>
> > other places when using git tools but not when using a
>
> > browser. I can download an archive from github when I point my
>
> > browse
Ben Fritz wrote:
> Because my workplace's IT somehow blocks access to github and
> other places when using git tools but not when using a
> browser. I can download an archive from github when I point my
> browser to the project webpage but git clone/fetch/pull all
> fail.
You know about $http_prox
> I meant for the web downloader, where does that come from? I assume always
> from git.
What web downloader? All sources are defined in VAM-kr.
> > You can use git archive from github, but this is a fallback option only in
> > case git, mercurial and bazaar executables are not available or mer
Excerpts from Ben Fritz's message of Thu Jan 02 17:37:09 +0100 2014:
> That looks cool...but where does it pull from? Some plugins I pretty
> much always pull from vim.org, other plugins I like downloading the
> latest revision in an archive from github.
vim-addon-manager-known-repositories default
On Thursday, January 2, 2014 2:40:38 PM UTC-6, ZyX wrote:
> > That looks cool...but where does it pull from? Some plugins I pretty much
> > always pull from vim.org, other plugins I like downloading the latest
> > revision in an archive from github.
>
> From wherever available. If VAM knows abou
> That looks cool...but where does it pull from? Some plugins I pretty much
> always pull from vim.org, other plugins I like downloading the latest
> revision in an archive from github.
>From wherever available. If VAM knows about git source it will use it. There
>is a setting to disable all so
On Thursday, January 2, 2014 9:40:49 AM UTC-6, MarcWeber wrote:
> Excerpts from Ben Fritz's message of Thu Jan 02 15:50:20 +0100 2014:
>
> > One reason I chose Pathogen was that my workplace blocks all git, Hg,
>
> > and SVN access that leaves our internal network. I'm forced to
>
> > manually d
Excerpts from Ben Fritz's message of Thu Jan 02 15:50:20 +0100 2014:
> One reason I chose Pathogen was that my workplace blocks all git, Hg,
> and SVN access that leaves our internal network. I'm forced to
> manually download zip archives to update my plugins. Anything using
> git directly without
On Thursday, January 2, 2014 8:33:42 AM UTC-6, herm...@free.fr wrote:
> Hello, and happy new year!
>
>
>
> > I've been thinking again about *why* VAM is viml only again.
>
> >
>
> > [...]
>
> >
>
> > If we'd use ruby gems it would be harder to declare package sources
>
> > in your .vimrc a
Hello, and happy new year!
> I've been thinking again about *why* VAM is viml only again.
>
> [...]
>
> If we'd use ruby gems it would be harder to declare package sources
> in your .vimrc and be done.
Yes indeed.
Please, stay clear of anything that is not viml -- or the system commands +
git,
I've been thinking again about *why* VAM is viml only again.
The reason is boottsrapping. My goal simplicity and determinism.
The goal was having a .vimrc is enough to bootstrap everything.
At list on linux like system it does work the way.
If we'd use ruby gems it would be harder to declare pack
http://vim-wiki.mawercer.de/wiki//topic/vipi.html
Can we collect wishes/features we want here on this page ? thanks.
Then we should just get it done this time.
Marc Weber
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replyi
Excerpts from Shougo's message of Tue Dec 31 11:02:02 +0100 2013:
> Yes, this knowledge may be not used in others. But it is only editor
> configuration! For example, Emacs' configuration knowledge can be used in
> other editors? It is not.
lisp is powerful. You're never learning a configuartion
In first, this thread is not about "Rewrite Vim by my like language".
>Your choice / my choice. I love Vim to. But I also think about all the
>people which are to be born which have to learn viml just to get a
>simple thing done in Vim - and you cannot reuse viml knowledge in any
>way. That's why
Sorry I didn't look at the links.
My point was not that VAM or NeoBundle or anything else was better and
should take over, but more that maybe we should rethink the way
plugins are defined. Maybe it's high times plugins actually declare
dependencies, where to be downloaded from, etc, so as to make
Excerpts from Adrien Piérard's message of Mon Dec 30 20:32:05 +0100 2013:
> A good example would be FreeBSD's ports, for which there exist several
> "clients" like portupgrade, porteasy, etc. This system has proved
> usable and used for long enough to be worth studying.
Yes, and gentoo portage, rub
So, there are a lot of package managers already, for various systems.
I'm wondering if we should leverage what's been done there already,
maybe not to reuse the clients, but to reuse the way the repositories
were defined.
A good example would be FreeBSD's ports, for which there exist several
"clien
Excerpts from Marcel Boon's message of Mon Dec 30 16:19:51 +0100 2013:
> I looked at Zimba and it looks really promising, but it is in early stage.
> Why do you think what you have in mind isn't possible with Zimbu? A
- compile time hackery like meta programming. Eg have a look at haxes or
Scala
> > We should respect the thought of Mr.Bram.
> You may do so and I respect them. Zimbu gets right what is was written
> for, but its not even close to what I have in mind - even though what I
> have in mind includes kind of Zimbu, but is not limited to it.
>
I sure do respect him too.
I looked a
> OK. I get it. It may be interesting suggestion. But it is a waste of time.
> It divides our community, needs our time, breaks compatibilities.
> I don't want to make another editor. I loves Vim(and VimL).
> You should solve other problems in Vim todo list.
Your choice / my choice. I love Vim to.
>Does neobundle allow loading a plugin immediately?
>Eg for VAM there are special options such as "load-now" so that you can
>even force loading the plugin/* files in .vimrc. Usual Vim behavior is
>load all plugin/* files after .vimrc has been processed by Vim.
>It is useful in some cases.
It seem
Excerpts from Marcel Boon's message of Mon Dec 30 12:14:48 +0100 2013:
> Major point is the embedding of vim, which seems very hard to do, it's on
> the vim wishlist for ages.
Please read the section about yzis (use wiki's search feature).
yzis was about that, and they finally gave up.
Blindly pat
> So if you're talking about the "real" thing also say why something is
"real" and the other is not.
I meant that emulating will be a substitute. Since NeoBundle and VAM both
have unique features so neither can emulate the other. Emulating NeoBundle
in VAM won't be the real NeoBundle, as emulating
> In install, neobundle don't care about install order.
> But, if plugin activation(lazy loading), is not. But it is too difficult to
> explain.
So eventually this could be of interest, too.
Does neobundle allow loading a plugin immediately?
Eg for VAM there are special options such as "load-now"
> I've tried creating a summary page which we can use to collect ideas
>
> about what is good/bad and how to improve in the future:
>
> http://vim-wiki.mawercer.de/wiki/topic/neobundle-vs-vam-merge
>
I think your plugin advantages are "integration with VAM-kr" contains
"addon-info.json".
>
>
I've tried creating a summary page which we can use to collect ideas
about what is good/bad and how to improve in the future:
http://vim-wiki.mawercer.de/wiki/topic/neobundle-vs-vam-merge
Shougo: When using vimproc and parallel processes, how do you feel about
activation order? In some cases order
I've also thought about parallel fetching, and this is the result:
What about parallel installation, fetching, activation, ... ~
Possible problems:
- activation order could be important, the plugin manager eventually does not
know (yet)
- Vim itself does not allow parallel processing
Excerpts from marcelspostbakje's message of Sun Dec 29 19:53:51 +0100 2013:
> I personally prefer the Vundle way.
Please let's not even start discussing unimportant details.
Of course VAM is fine with you using
call vam#ActivateAddons(['plugin1'])
call vam#ActivateAddons(['plugin2'])
In fact VAM
>starting new thread.
Thanks.
>Why does VAM cause that impression? The doc illustrates the minimal usage:
>set runtimepath+=PATH-TO-VAM
>call vam#ActivateAddons([.. list of plugin names ..], {'auto_install' : 0})
>and that's pretty minimal.
Yes. It is minimal. But it seems to configure p
On Sunday, December 29, 2013 3:59:21 PM UTC+1, MarcWeber wrote:
> starting new thread.
>
>
>
> > I used Vundle, but I want to change the behavior completely. So I created
> > neobundle.
>
> > I didn't know about VAM in that time.
>
>
>
> > I think to use VAM is too hard in Vundle user and t
32 matches
Mail list logo
