-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Refactor global variables to autoload variables #450
Conversation
I'm rather curious about the rationale behind this change. What does it give us? |
Ok I'm cool with that, but we must also be able to consume all the current variables that are already in place. Perpahs we could have a function to read them all from whatever sources and put them in a dictionary that we can use everywhere, so we don't have to do 20 ifs all over the place. Let's hear what @gmarik and @starcraftman have to say. |
Also, since you are "in the loop", it's more convenient to open your PR's against |
somehow my comment was duplicated and now that I removed the duplicate I cant see it anymore. Will repost. EDIT: Can I change the PR to be for |
The idea is to not pollute the global namespace with dfferent variables. A common prefix will make it clear where the variable belongs. |
I am not sure about renameing But if we do change it we might also give it a better name (at the moment it is long but uses an abreviation). some suggestions:
Also I would vote to rename |
or even |
@lucc Need to look this over further before more detailed comment but I believe we've been fairly consistent in not breaking any already existing apis. So yes, we'd have to make the new name an alias. |
To me a15b29d looks like it can be merged. It will change all global variables except for Also renaming of global variables like |
I rebased this on next and squashed the commits. It should only be merged after v0.10.2. |
@lucc I have re-read everything and I take back my objection. I'll be merging this as is. |
nice to hear, I was half hearty thinking this over but did not come up with a good idea. |
This made more sense this time than the first time I read it, apologies. |
The variable is script local to autoload/vundle/scripts.vim since #468.
These variables only occur in one file each. By making them script local variables this is "documented" in the code. At the same time the global namespace is polluted less. Changed: g:bundle_names -> s:bundle_names g:vundle_last_status -> s:last_status g:vundle_log_file -> s:log_file g:vundle_view -> s:view
I have rebased (actually rewritten) these commits on top of the current master. I have also split the work into different commits to better show what is done. |
@lucc looks much nicer! |
If it was loaded, unload the log buffer before editing it. Otherwise the editing command can "hang" if the user has `set hidden`. This problem was originally discovered with the VundleChangelog command and the analogous fix was applied in 7d9b10. See github issue #468 for more.
@jdevera I tried to apply your comment (sadly it is lost now, as the commit is gone) |
All global variables that are not part of the public API (mentioned in the documentation) are turned into autoload variables. This is intended to give all global variables defined by Vundle.vim a common prefix. The variable g:default_git_proto is part of the public API and is therefor not changed. This is the only exception. Changed: g:bundle_dir -> vundle#bundle_dir g:bundles -> vundle#bundles g:updated_bundles -> vundle#updated_bundles g:vundle_lazy_load -> vundle#lazy_load g:vundle_log -> vundle#log Unchanged: g:default_git_proto
The setting of the default values for the autoload variables is moved out of any function. One reason being that these settings do not depend on the argument of the function. The second being that Vim will source the autoload script if an undefined autoload variable is referenced and the file is expected to define the variable (see :help autoload).
I wish I remembered that comment :) |
I gave this a bit of a run and it seems solid to me. Merging. |
Refactor global variables to autoload variables
VundleVim/Vundle.vim#450 killed a bunch of globals.
VundleVim/Vundle.vim#450 killed a bunch of globals.
This is just an idea. If you like it I will continue to work on it. See commit message for more.