Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store bundles in a sorted dictionary #109

Closed
wants to merge 2 commits into from
Closed

Store bundles in a sorted dictionary #109

wants to merge 2 commits into from

Conversation

jdevera
Copy link
Contributor

@jdevera jdevera commented Nov 8, 2011

By storing bundles in a sorted dictionary (dictionary + list of keys), the bundle does not need to be reparsed during installation if it has already been initialised, and any additional options passed in the original command are kept.

This changeset is also an initial attempt to stabilise the name vs spec naming convention, where a bundle spec is whatever is used to specify a bundle, be it a name, user/name, full uri, etc., and name is the name of the bundle that will become a directory under the bundles directory.

This changeset is the foundation for a couple more that I intend to implement, I've listed them as issues in my fork, please let me know what you think.

I have tested these changes with a modification of the minimal vimrc (to include couple more bundles) and with my own vimrc with some modifications to make it compatible (I'm stuck in the events branch, but this is one step on the way out).

Also, I added some comments while I was trying to figure out the code, I left them there, I thought they wouldn't do any harm.

So, what do you think, is this vundle material?

This is in response to the conversation in #87

By storing bundles in a sorted dictionary (dictionary + list of keys),
the bundle does not need to be reparsed during installation if it has
already been initialised, and any additional options passed in the
original command are kept.

This changeset is also an initial attempt to stabilise the name vs
spec naming convention, where a bundle spec is whatever is used to
specify a bundle, be it a name, user/name, full uri, etc., and name is
the name of the bundle that will become a directory under the bundles
directory.

closes #1
@gmarik
Copy link
Contributor

gmarik commented Nov 9, 2011

Hey @jdevera.
Sorry for taking so long to respond...

Don't have the answer yet...
Need to dig into...stay tuned...)

This changeset allows the second parameter of the Bundle command (a
dictionary) to override bundle object fields that come from parsing the
bundle spec. This means that
 Bundle 'abolish.vim', {'name' : 'abo'}
will be installed in a bundle directory named 'abo', rather than
'abolish.vim', which is the name parsed from the bundle spec.
@jdevera
Copy link
Contributor Author

jdevera commented Nov 10, 2011

I just added a little something that was missing, please consider the second commit as well (that one won't take you a long time)

@greduan
Copy link

greduan commented Dec 2, 2012

@gmarik Just a reminder. I'm gonna do this a lot. lol

@MarcWeber
Copy link

Speed improving ideas: #131, #364. I've no idea whether this is still valid, I didn't check

@ches
Copy link

ches commented Mar 22, 2014

The abstraction of the object looks nice. Seems like that might be helpful for exploring implementation of optimizations like one-shot augmentation of the runtime path under discussion in #403. Also probably relevant for handling lazy-loading strategies like #98.

@jdevera
Copy link
Contributor Author

jdevera commented Apr 4, 2014

Although I think this implementation was superior, since it used Viml dictionaries rather then iterating on lists, the problem this solved no longer exists, since we now reuse previously loaded bundle objects.

So closing. But I might come back 😄

@jdevera jdevera closed this Apr 4, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants