-
Notifications
You must be signed in to change notification settings - Fork 59
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
plugin after/ paths should be placed before user's after/ path on &rtp #165
Comments
You have to think diffently about VAM's reccomendation about .vimrc and what VAM does. So maybe you want to prefix rtp by VAM's runtime path so that VAM can be loaded at all. Maybe everything is fine then for your case. Its hard if not impossible for VAM to know which after path should be latest. Maybe the best way would be adding another hook to allow the user to override the "add rtp" implementation. |
I realize there's some challenge/ambiguity making it work properly, but I don't think the user will generally know better than their plugin manager how to handle rtp. For the vim-addon-manager entry itself, I think it's fine that it's initially added in the wrong place, but VAM could detect and correct that wrong ordering in initialization. |
Eventually you should start talking about the "real" problem you have. |
The concrete problem is when a plugin defines say after/ftplugin/cpp.vim and you define ~/.vim/after/ftplugin/cpp.vim, and suddenly your settings are being overridden and it's impossible for you to fix. My "real" problem is just that I want to recommend VAM to friends at work, but can't stomach adding another gotcha for me to check in every troubleshooting session. There's a delicate balance of layers of user/plugin/system overrides and arbitrarily changing precedence on those groups can have seriously unpredictable results. My runtimepath looks fine when I use just maktaba to manage it but after I install any plugin using VAM, that and all subsequent runtimepath modifications have the wrong precedence. |
Well - VAM's idea also is "why not package your own ~/.vim as plugin" - and then its no longer that easy to understand what a plugin and what your after directories are. Anyway: I see two fixes
I guess that 4) would be most usable because it would not depend on loading order of plugins Do you think it would make your case "usable"? We could even make it default to [$HOME/.vim (or _vim)/after] directory |
Yes, I think option 4 is a good approach provided it includes reasonable defaults (hopefully including the defaults for other common platforms as well). Thanks for being accommodating of my corner cases! |
The problem is that none of the following categories exist in
. I think this is enough to resolve your issue: just when modifying
. I do not like other solutions because
|
I like the concept of VAM being detecting paths it didn't add and avoiding modifications to them, but it sounds like you're suggesting that (by default) system paths should have higher precedence than VAM plugins. That sounds pretty extreme. I agree there's a cost to adding a new option and it may not be the right approach. But I strongly disagree that this is a "fringe feature", unless you're arguing after/ files are in general (and if so, why does VAM bother to add them to runtimepath?).
What do you mean by "be used"? If you mean changing this "keep_rtp_last" setting from it's default, I don't even plan on doing that, because the default $HOME/.vim/after is all I need, along with most other users. I'd be just as fine with just changing this "default" to a hard-coded list in VAM as long as it includes a good set of reasonable guesses, but if you did want to make it a setting it would be a nice acknowledgement of the fact that it's a guess, and an escape hatch for users with weird nonstandard config paths that happen to notice (after a long horrible troubleshooting session) that their settings are being overridden by a rogue plugin file, so they have some option besides just uninstalling the plugin. |
I'm tired of talking. Can you give this patch a try? |
-----BEGIN PGP SIGNED MESSAGE----- On November 19, 2014 8:00:42 PM EAT, David Barnett notifications@github.com wrote:
Ah, this was an accident. Should swap first two arguments. (Maybe better to have non-VAM non-after (nVnA), non-VAM after (nVA), VnA, VA in function arguments and VnA, nVnA, VA, nVA in the result).
Problem is that they will not know this option unless they read source code, are proficient at guessing how this option should be searched for or have memorized our documentation.
-----BEGIN PGP SIGNATURE----- iQJNBAEBCgA3BQJUbOGoMBwfMDI7PjIgHTg6PjswOSAQOzU6QTA9NEA+MjhHIDxr |
http://mawercer.de/tmp/vam.patch now adds this option to README.md. Vim is broken in many ways, eg see this: http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-vim-suck.html |
Patch seems to work. FWIW, if rtp manipulation code is performance critical in VAM (parts of it are for maktaba), I saw some potential optimizations in the patch code like only evaluating $HOME once, using \V (very nomagic) on the regex instead of using escape(), and looping over rtp entries once instead of twice for the filter(). |
I've pushed the patch I proposed. If ZyX comes up with something better he's welcome to reopen and propose another fix. @dbarnett I don't want to over optimise VAM code. neovim might change a lot (by using lua as default language) anyway. |
@MarcWeber Sure. I figured VAM planned to support classic vim for a while even if neovim changes everything soon (and the regex thing was more about safety), but point taken. Anyway, thanks for the fix. I'll consider it subject to change, but would appreciate a ping here if it does change. |
Vim's runtimepath should have the following categories in order:
This lets the user run both first and last, and similarly gives plugin files priority over system files. See
maktaba#rtp#Add
, which tries to preserve that ordering.VAM seems to always put plugin after/ paths at the very end, preempting the user's after/ path. The end of my runtimepath looks like:
It has the wrong precedence and also confuses other runtimepath manipulation utilities like
maktaba#rtp#Add
that use heuristics to try to insert plugin after/ files in the right order. The vim-addon-manager entry itself also ends up too late in the order after the recommended VAM setup.VAM should take more care to maintain a good runtimepath order.
The text was updated successfully, but these errors were encountered: