Which plugins make assumptions about current directory - vim

I'm thinking about setting the following in vimrc
set autochdir
In vim.wikia.com it states that
...Unfortunately, when this option is set some plugins may not work
correctly if they make assumptions about the current directory....
Am I better just changing the working directory manually when required? Which plugins will not work properly when using autochdir?

I've been using :set autochdir since I've started with Vim in 2002, I use a lot of plugins, but I haven't experienced many problems. (And those problems were rather easy to fix; I think I've sent some such patches to plugin authors.)
In the end, it greatly depends on the individual plugins. Don't be afraid and just try it; it's trivial to switch back, anyway. Look out for problems with plugins that create new buffers or access / navigate to other buffers, especially when those are distributed over different directories. Problems ususally manifest themselves into the wrong buffer (or an empty one in the wrong directory) being opened.

Related

How to change vim colorscheme to point to different directory

I'm wondering whether I can change 'colorscheme' to point to different directory.(rather than default) since I want to set my all my color schemes in vimrc file with my own directory.
In My MacOS, the default directory are in /usr/local/share/vim/vim80/colors
You are supposed to put colorschemes in ~/.vim/colors/.
Create that directory if it doesn't exist and stay away from /usr/local/share/vim/.
As #romainl pointed out, keep your hands off the system-wide directories. Just because Vim's default stuff gets installed under /usr/local/share/vim, this doesn't mean that your personal extensions and customizations should be in there as well. You'll provoke problems when upgrading or reinstalling Vim.
If the suggested default location (~/.vim/colors/) doesn't suit you, you can add additional directories to 'runtimepath' (early enough; i.e. in your ~/.vimrc). For colorschemes, the direct directory has to be colors, though. To work around that, you'd have to use filesystem links to create an alias.

Mulitple vimrc-files, multiple vim-directories.

I'm trying to get better with Vim at Ubuntu 14.04, but I struggle to understand it's structure. I've been Googling around for quite some time, but this questions I haven't gotten answered anywhere.
I'm trying to install some plugins and make a good .vimrc-file for myself, in the future. But when I have to install plugins, then the Readme-files tell me, to put the files in the 'plugin'-directory in the vim-folder. But I've discovered that I have two vim-folders:
- One in /etc/vim/
- and one in ~/.vim/
I tried putting the plugin in each folder, and it worked, in the latter one. But I don't understand why. Can anyone explain it?
And it's the same thing for the vimrc-file. If I run a :version in vim, then I get, that there's a vimrc-file here /etc/vim/vimrc and theres one here ~/.vimrc . Now - why is one hidden and one is not? I'm a Windows-kid originally, and if confuses me, because it looks like that the format is different, from one file to the next. But mainly; where is it good manners to insert the custom changes to the vimrc-file? For the system-vimrc file, or for the user I'm using?
Files and directories under /etc/vim/ make up Vim's system-wide runtime files.
You must never touch them.
because they will be overwritten next time you update Vim,
because messing with them puts Vim in an unstable state,
because you need to escalate privileges.
All your configuration must happen in your $HOME:
your settings/mappings go into ~/.vimrc,
your plugins and colorschemes and anything you download from third parties go into ~/.vim/.
That said, most (all?) plugins clearly use ~/.vim and ~/.vimrc or their $HOME variants in their install instructions. If they don't, complain to their author.

Vim file explorer with random multiple roots

One thing I like about Sublime Text is that you can drag any folder in the left panel and this folder can be expanded independently from the others. How can I achieve the same functionality in Vim?
I'm currently using NERDTree which currently supports a single root. When you open another folder it replaces the current hierarchy. So I wouldn't mind dropping this plugin in favor of another solution.
The netrw plugin that ships with Vim allows to open multiple, different splits to different locations, e.g. vertically with :Vexplore.
To make it show a recursive tree, use:
:let g:netrw_liststyle=3
I don't know any plugin that does this, but from my brief forays into NERDTree's source code, I know that modifying the plugin to do what you want is not out of the question. It would involve delving into the logic and modifying / commenting out the parts that search and re-use the current NERDTree buffer. If you're familiar with Vimscript, not a huge challenge. (Maybe you could even introduce a configuration setting for it and send it to the author for inclusion.)
It took me a while, but I managed to work something out.
I made it into a separate plugin: Vimpanel
I put a lot of other usefull things in there, apart from the "killer feature" of being able to have multiple roots.

Load the ftplugin folder via janus

I posted an issue at github about this as well, but I figured this would also be a good spot to ask:
Does anyone know how to accomplish this functionality? I've been trying for the past couple of days to figure this out all to no avail aside from putting directly into my ~/.vim/ folder.
I'm trying to install the jslint ftplugin to give me error highlighting while eding javascript files. I have tried all the following combinations to try and get this ftplugin to work within the contexts of janus:
~/.janus/langs/javascript/ftplugin/jslint/
~/.janus/ftplugin/javascript/jslint/
~/.vim/janus/vim/langs/javascript/ftplugin/jslint/
~/.vim/janus/ftplugin/javascript/jslint/
All of those above fail to recognize this ftplugin. The only one that works is this:
~/.vim/ftplugin/javascript/jslint/
but that is not ideal since this is not core to janus. Any ideas on where this folder (or any other ftplugin folders for that matter) can be put so macvim to recognize this functionality?
The solution to this is to put it in
~/.janus/jslint/ftplugin/javascript/jslint.vim
Each folder inside the .janus should have the same file structure as a normal .vim folder. (So the ~/.janus/jslint folder is equivalent to .vim)
Note janus made this task really hard. Using plugin distributions like janus might lead to easy set up in the beginning but changing them or debugging them will be hard. You should set up your vim environment the way you want so that you know everything in it. This will lead to easier maintenance later on in life. And you will know how to use everything because everything was installed one at a time instead of all at once.

How does vim-pathogen make anything easier?

If I understand it correctly, with pathogen it makes things easy because all you have to do to install/uninstall plugins is place or remove the plugin from a certain directory.
But isn't this what the plugin directory is for? How is it any better?
A plugin can be a single plugin_name.vim file that you toss into ~/.vim/plugin/. If every plugins were single files we wouldn't "need" any plugin management solutions.
But most plugins are actually collections of files that need to be placed in certain directories like ~/.vim/autoload/, ~/.vim/after/, ~/.vim/doc/ and so on. This has been considered "messy" for a while and Pathogen is one of many answers to this problem:
Vimball :help vimball
Vundle
VAM
VAM
Unbundle
possibly others…
If you don't think that it's a problem then you obviously don't need a solution (pathogen or whatever).
I think that it's a problem (I like my things well organized), Pathogen is the first solution I came across and it served me well.
It's better because you can store your plugin in isolation in the ~/.vim/bundle directory. That makes easier for you to have all your configuration directory under a version control system. Take a look at my vimfiles for example.
All the plugins I use are stored as a git submodule and this makes updates easy to handle. Furthermore, if you want to remove a plugin it's just a matter of removing the relative directory in the bundle one.

Resources