collaborate with Shougo's NeoBundle

[marco-oweber]

https://github.com/Shougo/neobundle.vim/issues/117

[Shougo]

Thanks.

I created for VAM-kr branch.

https://github.com/Shougo/neobundle.vim/tree/vamkr

[Shougo]

Suggestions:

• I think VAM-kr database should not contain VAM(VAM-kr) functions.

For example, vam#utils#RunShell(), vamkr#AddCopyHook(), vam#utils#CopyFile(), vam#utils#RmFR().

• patchinfo.vim and scmsources.vim use terrible global variable name g:r.

• patchinfo.vim and scmsources.vim should be dictionary instead of list.

[ZyX_I]

1. I am highly against replacing vamkr#AddCopyHook with direct hooks operations: it is here to avoid lots of copy-paste for specific type of hooks. vam# functions you mentioned are a separate issue, but the best thing I can suggest is copying them to VAM-kr. Replicating their functionality in hooks makes them too complex.
2. It is not a global variable. Just don’t try to :source.
3. They do contain dictionaries. Just they contain more then one dictionary.

If you choose to import pool why not use predefined function VAM uses (the ones that are defined in VAM-kr repository)? These files contains data in format that is easy to write, function returns data in format that is easy to work with. It is easy to make these functions not depend on VAM-specific stuff.

[Shougo]

I am highly against replacing vamkr#AddCopyHook with direct hooks operations: it is here to avoid lots of copy-paste for specific type of hooks. vam# functions you mentioned are a separate issue, but the best thing I can suggest is copying them to VAM-kr. Replicating their functionality in hooks makes them too complex.

I think VAM-kr should use another attribute for it. Like this:

"let scmnr.2780 = vamkr#AddCopyHook({'type': 'git', 'url': 'git://github.com/mjbrownie/Python-Tag-Import'}, {'python_tag_import.vim': 'ftplugin'})
let scmnr.2780 = {'type': 'git', 'url': 'git://github.com/mjbrownie/Python-Tag-Import, 'files' : ['ftplugin/python_tag_import.vim'])

[Shougo]

It is not a global variable. Just don’t try to :source.

OK. It is not problem.

They do contain dictionaries. Just they contain more then one dictionary.

I think dictionary is better. Because json file is VimL's dictionary.

"let r=[patch_repo, addon_info, addon_info_deps, renamings]
let r= {'patch_repo' : patch_repo, 'addon_info' : addon_info, 'addon_info_deps' : addon_info_deps, 'renamings' : renamings}

[Shougo]

If you choose to import pool why not use predefined function VAM uses (the ones that are defined in VAM-kr repository)? These files contains data in format that is easy to write, function returns data in format that is easy to work with. It is easy to make these functions not depend on VAM-specific stuff.

neobundle has build feature. I think it is better.

[ZyX_I]

You should use another attribute for it.

It was implemented like a workaround for authors who do not follow conventions established (due to pathogen/Vundle) long before we had hooks. I rather prefer not to have this in the core. I can though make functions that process pool fix it (i.e. remove the key if it is present and call vamkr#AddCopyHook), but this will be implicit and require explanations that (unlike other keys documented in VAM) can only be given in VAM-kr because it would be VAM-kr and not VAM functionality.

I do not see this functionality in NeoBundle either except for possible implementation using build key.

neobundle has build feature. I think it is better.

I see things like 'windows' : 'make -f make_mingw32.mak', in examples meaning that this feature is restricted to shell code. Using vim mkdir(), rename() and vam#utils#CopyFile is more portable. Also hooks in VAM are sometimes used to patch Makefile (see vimscript #4637). It is trickier to write them for windows given that sed.exe should not be a requirement.

Your variant definitely looks cleaner, but our provides more features and is easier to make portable.

[marco-oweber]

I feel the most important thing is to think about whether we want to continue both projects, or join efforts for obvious reasons. NeoBundle and VAM solve the same problem - but there are some differences, eg NeoBundle supports async installation, VAM does not. VAM uses addon-info.json files, NeoBundle does not. Lazy loading is different, but the difference is very small. I didn't try to implement async updating/installation because it could cause inconsistent state, eg a mapping could trigger loading a plugin which didn't finish checking out. If you want to update its trivial to run two Vim instances for instance.

[Shougo]

I feel the most important thing is to think about whether we want to continue both projects, or join efforts for obvious reasons.

I want to continue neobundle project. Because, I like neobundle. But some VAM's feature may be included. For example: for VAM-kr converter. I want to add support for archives in neobundle.

VAM uses addon-info.json files, NeoBundle does not.

Yes. But I can implement for it. I have written converter for VAM-kr.

[Shougo]

Also hooks in VAM are sometimes used to patch Makefile (see vimscript #4637). It is trickier to write them for windows given that sed.exe should not be a requirement.

Oh.... It is tricky. If VAM-kr is for VAM only, it is OK. But for "collaborate with Shougo's NeoBundle" is not. I think VAM-kr(repository information) should not depend on VAM or VAM-kr or other plugin(contains neobundle) functions. I think it should be used more globally.

[Shougo]

What's the VAM-kr's license? I can't look for it. It is important.

And "VAM-kr" is for VAM name. I think you hould change the repository name like "Vim-plugins-known-repositories" if you want to collaborate with other plugin managers. It may be standard plugin repository. I want to commit your repository for this collaborate.

[marco-oweber]

I'm fine with renaming, I'm fine with granting you commit access. ZyX, how do you think about it? At least till we have more time (to create a true website out of it) keeping it this way might be an option But in the long run we should have a service IMHO

[Shougo]

Thanks.

[ZyX_I]

@MarcWeber I am fine with renaming as long as you use github redirections (or how this feature is named) to make either old or new name point to the same location.

Suggested name (vim-plugins-known-repositories) is not fine since it is too verbose and does not even have nice abbreviation. Even ViKR (full name is same, but without -plugins) is nicer. ViPI (Vim package index) would be good, but it is easy to guess how it is related to PyPI (python package index) (it is borrowed from there). Cannot think about good unique name right now. Given my names you know (e.g. frawor which is nothing more then framework) it is probably better to ask this question on vim-use (not vim-dev because we need designers and vim-use provides better chances to find one) and your suggestions on various names I know we will have to spend infinite time to create something like pypi without borrowing it from somewhere.

I do not see why you should not grant commit access to @Shougo.

[Shougo]

Suggested name (vim-plugins-known-repositories) is not fine since it is too verbose and does not even have nice abbreviation. Even ViKR (full name is same, but without -plugins) is nicer. ViPI (Vim package index) would be good, but it is easy to guess how it is related to PyPI (python package index) (it is borrowed from there).

OK. VIPI seems good.

[marco-oweber]

Excerpts from Shougo's message of Tue Dec 31 09:35:15 +0100 2013:

Suggested name (vim-plugins-known-repositories) is not fine since it is too verbose and does not even have nice abbreviation. Even ViKR (full name is same, but without -plugins) is nicer. ViPI (Vim package index) would be good, but it is easy to guess how it is related to PyPI (python package index) (it is borrowed from there).

Do want a github/VIPI/ account or such then ? then we could add both VAM and neobundle to that new account.

This would emphasize that we want to serve the community together using one project in the future.

[Shougo]

Do want a github/VIPI/ account or such then ? then we could add both VAM and neobundle to that new account.

Oh, it is nice idea.

This would emphasize that we want to serve the community together using one project in the future.

Yes. I agree with you. It may be standard plugin information repository. If one of them cannot continue working it, others people can join it.

[marco-oweber]

Which is the best way to move on? Create a new gmail email account? Then share the password for Shougo, ZyX, me? Then use it to create a new github acocunt ? Then move the code there? Then discuss details about what to improve in which way?

[ZyX_I]

OK. VIPI seems good.

If you do not want to ask on mailing list then ViKR is at least rather unique. ViPI means we will be always compared with PyPI.

Which is the best way to move on? Create a new gmail email account? Then share the password for Shougo, ZyX, me? Then use it to create a new github acocunt ? Then move the code there? Then discuss details about what to improve in which way?

Github account… there are examples of project-specific accounts like libgit2. Do they use what you suggested? Bitbucket has team accounts for this task and I just succeeded to create one for testing (needed a new email for this task though): seems really easy. If you are fine with bitbucket you can use your github or google account to sign up there and I send you invitation. Github does not has that big menu Teams with button Create team so I have to do some googling to find that most likely creating new organization is what is needed.

Note: I cannot use github to create organizations named vipi or vikr: names are already taken. Name vim-known-repositories was not (taken by me right now), but it is too verbose: bitbucket.org/vikr/vikr or bitbucket.org/vipi/vipi (I reserved both team names just in case) is better then both github.com/vim-known-repositories/vim-known-repositories (reserved) or github.com/vim-package-index/vim-package-index (not reserved: somebody reserving vipi is more likely then somebody reserving vim-package-index). Using both full and abbreviated name is inconsistent with nearly all similar “organizations” and will still be too verbose. All changes are AFAIK undoable: you can delete bitbucket teams as well as github organizations.

[marco-oweber]

What about github/vim-plugin-index ? I like simple descriptive names

[ZyX_I]

It is too long. Worse, its abbreviation is still ViPI. I do not like typing such very long names and in any case people will use abbreviations. Remember, you do not always use bookmarks or copy-paste to write URL. And you always use abbreviations for too long names: could you count how many times VAM-kr was written here compared to vim-addon-manager-known-repositories? Or how many times have you written VAM and vim-addon-manager when advertising?

You already have my damns for having to type github.com/MarcWeber/vim-addon-manager[-known-repositories]. Typing vim-plugin-index cannot be reduced by even github redirections(?) because it is organization name.

Many users in any case will learn abbreviation first just because whoever will be advertising new entity is too lazy to type full name. Then why should URL contain full name? Google for VAM-kr: first result is vamkr.vim file (created by me), second is neobundle issue, third is mention of vamkr#AddCopyHook in this issue, fourth is @Shougo activity tab, all other results on the first page have nothing to do with VAM-kr. (VAMKR without hyphenminus has a few relevant results all joined by google into one item under file vamkr.vim and not a single relevant item below the first one.) I am saying that you will have to spend some effort on SEO for abbreviation you will advertise while with vikr directly in project name you have good head start because vikr will be placed in the page title by bitbucket.

Also note that google shows more then one thing abbreviated by vipi when searching for this and only a few nicknames while searching for vikr.

[Shougo]

OK. What about "vim-pi" or "vimpi" ? I searched it, but not found.

[ZyX_I]

vim-pi (assuming we use “vim plugin index” as a full variant) is a lot better then vipi and better then vikr. I would rather still ask on vim-use (due to -pi part), but if you are not going to do this it is acceptable name.

[marco-oweber]

I'd liek to rethink everything again. What about github.com/vim-community/vipi or such? Then we could add a lot of additional community maintained projects too. To my mind come my ultisnips fork, snipmate, vim-snippets, maybe even vim-runtime (there is a lot to improve and fix), maybe even Vim.

[marco-oweber]

About typing: http://plover.stenoknight.com/ :) (I don't use it myself ..). Also in browsers etc caches work quite nicely. Eg in chrome typing "gith kno" is enough, then you can select the url from cache :)

[ZyX_I]

I'd liek to rethink everything again. What about github.com/vim-community/vipi or such? Then we could add a lot of additional community maintained projects too. To my mind come my ultisnips fork, snipmate, vim-snippets, maybe even vim-runtime (there is a lot to improve and fix), maybe even Vim.

What is “vim community” and how it “maintains” these projects? I.e. define structure of the organization: who maintains what, how maintainers are assigned, how projects are added, etc. It is something that must be discussed on vim-use or vim-dev and not here. And also note that I am against moving Vim to be maintained on github because github implies git.

I would just stick now with github.com/vim-pi/vim-pi (better if it would bitbucket (though with git due to --depth) as it has better bug tracker). It not too hard to move vim-pi anywhere else.

About typing: http://plover.stenoknight.com/ :) (I don't use it myself ..). Also in browsers etc caches work quite nicely. Eg in chrome typing "gith kno" is enough, then you can select the url from cache :)

Chrome cache is especially helpful if I type in gmail app on my smartphone, in other application (e.g. in psi) or at a computer that does not belong to me.

[marco-oweber]

github implies git. git is cool, because "its stupid" and its efficient (it allows shallow clones). Its used by most plugins. Whenever I tried hg it got into my way, git never did. There is also my vim-wiki, maybe even vim-scripts people would join. But you're right, let's take this discussion to vim-use.

[ZyX_I]

Of course hg got in your way. I guess git is what you learned first because mercurial was first thing I learned and I say the same for git. Bitbucket allows both git and mercurial, but Vim is using mercurial and it should continue to use it.

[Shougo]

I think git (with github) is better. Because, github has many users and more Vim plugins than bitbucket. "Many users" is important.

Yes. Mercurial has good features(like MQ). But it is slower than git. I don't want to use hg repository.

And, if this repository is hg, repository users must install "hg"(not developers). I don't want to do it.

[marco-oweber]

Excerpts from Shougo's message of Fri Jan 03 02:36:54 +0100 2014:

I think git (with github) is better. Because, github has many users and more Vim plugins than bitbucket. "Many user" is important. But we cannot but a hg fork of Vim there. In the long run we need more changes than a plugin manager IMHO.

Marc Weber

[ZyX_I]

I think git (with github) is better. Because, github has many users and more Vim plugins than bitbucket. "Many users" is important.

As a good addition to other bitbucket features it would be good to convince a number of plugin authors not to use github. It is currently a very huge single point of failure with the damage in case of bringing it down comparable to the one in case of bringing down Google (to the vim community, not total).

[Shougo]

As a good addition to other bitbucket features it would be good to convince a number of plugin authors not to use github.

What are the features? Please explain them.

[ZyX_I]

What are the features? Please explain them.

1. Obviously, mercurial support.
2. Github issue tracker has milestones and labels support. But all of them can only be assigned by repository owner or somebody with commit access. Bitbucket does not have labels, but it has components and kind (these two cover what labels are usually used for), milestones, versions and priority. All may be specified by issue creator.
3. Bitbucket issue tracker has attachments.
4. Bitbucket issue tracker can be configured to send emails to mailing list when new issue is created or updated. I did not use this, but guess it is the same functionality Bram has configured for vim issue tracker.
5. Bitbucket issue tracker can export issues and import them. Never used this functionality though, so can’t say how it is helpful.
6. Bitbucket allows to restrict commit access to certain branches. It also allows making some bookmarks (mercurial equivalent for git branches in addition to actual mercurial branches) non-removable.

The downsides I know are: pull requests have separate numbering and pull requests do not get automatically updated when author of the PR pushes. Bitbucket PR have approve button, but I am not mentioning it as an advantage: https://bitbucket.org/site/master/issue/6565/need-a-reject-as-well-as-approve-bb-7750 (no “reject” button and also approves do not get reset when PR is updated).

Other issues which show bitbucket disadvantages compared to github:

• https://bitbucket.org/site/master/issue/8548/better-ci-integration-add-a-build-status (show CI build status near commits);
• https://bitbucket.org/site/master/issue/5231/pull-requests-should-update-with-newest (PR does not get updated when you push).

[Shougo]

Thanks. I get it.

[ZyX_I]

Obsoleted by #83, #82, #81, #80.