I am using mac vim in terminal via /Applications/MacVim.app/Contents/vim
By now I didn't really care about what was in the MacVim directory in /Applications/MacVim.app/Contents/Resources/vim/runtime
and still somehow I had proper syntax highlighting etc.. I guess my vim loaded the files from macvim?
Somehow I messed arround with snipmate and all the syntax highlighting stopped to work. Filetypes are correct, but no highlighting. So I copied the syntax folder from the macvim app to my ~/.vim/syntax and it worked like a charm. Is there a way how I can use the ones from the app again?
Thanks for any help
Copying the syntax to your own ~/.vim/ directory effectively forks the factory-defaults. The downside is that you now have to update your copy whenever Macvim is updated.
The key to figuring out the problems is the 'runtimepath' setting. By modifying that (in your ~/.vimrc), you should be able to include the proper runtime files (and that is not just syntax, but also filetype plugins, should you have :filetype plugin on). BTW, it's unlikely this is caused by snipMate.
:set runtimepath?
Also, the :scriptnames command tells you exactly which scripts have been sourced so far.
Related
I closed a vim window completely (something I rarely do) and when I opened it back up my syntax highlighting for jsx files stopped.
I had some other windows open and inside these the syntax highlighting for jsx was still working.
I compared the filetypes in both and could see that the ones that were still working were set to javascript.jsx and the exact same files in my new window had a filetype of javascriptreact.
Then I shut down all windows to see if reloading all would have an effect, and now all my .jsx files come up with filetype of javascriptreact with no proper syntax highlighting (especially jsx parts).
I didn't intentionally change any config options that I'm aware of, and am using vim-jsx plugin.
Does anyone have any idea of what might be going on? I am getting the same behavior in terminal Vim and in MacVim.
It's worth noting that when I manually set the filetype back to javascript.jsx it doesn't have an effect.
Help!
Ok, this is embarrassing, but apparently this line got removed from my .vimrc.
execute pathogen#infect()
So none of the plugins in ~/.vim/bundle were loading. Still not quite sure how that happened, but I suspect carelessness on my part rather than foul play.
Anyway. I survived to code another day...
I uninstalled vim74 and compiled vim81 and installed it. However I found it strange, comparing to vim74. When there's no .vimrc file under HOME dir, I open a c++ file and syntax highlight is working and I can use Backspace to delete letters. However when I add a .vimrc under HOME dir and just put set number into it, when the c++ source file is opened, no highlight, and Backspace not working. Why is that ? I used to add some configurations in .vimrc under vim74 before, and this situation never happens.
After complaints that Vim in its default configuration is hard to use (especially for beginners), it was decided to enable a default configuration if the user hasn't created his own ~/.vimrc (yet). This was introduced with Vim 8.0, and explains what you're seeing (namely: syntax highlighting and sensible backspace behavior). Read more about the details at :help defaults.vim.
The help also has instructions how to keep the defaults when adding your own ~/.vimrc configuration:
If you create your own .vimrc, it is recommended to add these lines somewhere
near the top:
unlet! skip_defaults_vim
source $VIMRUNTIME/defaults.vim
Then Vim works like before you had a .vimrc.
Tip: Don't go all crazy with adding various snippets (especially not those you don't fully understand) and plugins to your ~/.vimrc, even though the Internet is full of them. Rather, build it up gradually, depending on needs, and back up your understanding with careful studying of the excellent :help. Also, avoid pre-packaged Vim distributions; they're even worse.
I'm trying to install delimitMate on vim version 7.3. I am using Pathogen. My other pathogen bundles work, so it is not a problem with my setup.
In fact, I've also tried auto-pairs and ClosePairs plugins too, and none of them work. I don't know why? Am I using it wrong? Shouldn't a matching paren simply follow when I put an opening paren (similar to sublime Text?)
The commands :DelimitMateTest and :h delimitemate works, so the script is being executed. It's just not actually autoclosing any parens, and I can't figure out why.
Here's the output file for :DelimitMateTest: http://pastebin.com/2WtHVZJL
Any ideas as to why I can't get paren completion from any plugin?
Thanks!
For those of you who come across this problem in the future:
I had set paste in my .vimrc. This permanently disables several other features, and it was messing up key mappings. Simply remove it from your .vimrc and you should fix your problem.
I've been using Vim and pathogen for a while, and things were working fine, but recently I've started having load order issues with my ftplugin configuration.
The specific problem I'm having right now is that python-mode is overriding my ftplugin settings. I've got a ~/.vim/ftplugin/python.vim that contains the following line:
setlocal textwidth=119
python-mode comes with its own ftplugin file, which also sets textwidth, in ~/.vim/bundle/python-mode/ftplugin/python/pymode.vim.
The problem is that Vim is now loading python-mode's ftplugin file after my ftplugin file, so I'm ending up with its textwidth=79. I recently had to reinstall MacPorts, and I think something must have changed in the stock configuration.
I've tried various tricks involving turning filetype/plugin detection off before invoking pathogen, per various other answers, but none of them are helping.
Through the use of verbose set textwidth? and some echomsg debugging, I know that both ftplugin files are being invoked, and that they're being invoked in the wrong (for my needs) order.
Is there any way to force Vim/pathogen to invoke my ftplugin files after those of the plugins?
I've even tried putting my settings into ~/.vim/after/plugin/pymode.vim, but that's loaded immediately after pathogen sets up the plugin, so it still runs before ftplugin files, which only get loaded once I edit a Python file.
It turns out that maybe this never worked the way I thought. I didn't realize that Vim also supported ~/.vim/after/ftplugin, so I was able to move my overrides to ~/.vim/after/ftplugin/python.vim and get the behavior I was expecting. I'm loath to answer my own questions on SO, but hopefully this will help someone else.
Plain Vim loads the plugin scripts in alphabetical order. This is from :help load-plugins
... all directories in the 'runtimepath' option will be
searched for the "plugin" sub-directory and all files ending in ".vim"
will be sourced (in alphabetical order per directory), also in
subdirectories.
So you can set plugin loading order by renaming <filetype>_plugin.vim to <filetype>/35plugin.vim. 35 is your desired loading order. I think this should work with Pathogen too by renaming the plugin directories inside bundle, but I haven't tested it.
I'm still looking for a more general answer to this load-order issue
As far as I know, you can't really do it with Pathogen. It is really easy with NeoBundle. Pathogen is really minimal, it doesn't provide you with a lot of flexibility - it does only one thing and does it well. If you're looking for configurability, I think you're using the wrong tool.
EDIT: Not really sure about ftplugins, but bundles in general are loaded as you specify them (with Vundle/NeoBundle). So I realise that this maybe is not the most relevant of answers.
I'm experiencing a very slow startup of gvim with tex files and the latex-suite plugin. For example, opening this tex file takes 7 seconds. A minimal .vimrc file only contains the following line:
filetype plugin on
My .vim folder only contains the latex-suite plugin (snapshot 2013-01-16). I suspect the folding functionality in latex-suite but I'm not sure how to track this down properly and fix it. I'm running gvim 7.3 on Ubuntu 12.10.
Does anybody know how to fix this slow startup?
If the problem is related to the filetype (as you've already determined), the slowness should also happen when you :edit the file from within a running Vim, or even when you reload the Tex file via :e!. I'd use that to investigate the root cause. If you suspect folding, :setl foldmethod=manual or :setl nofoldenable would be a first attempt.
Since you've already isolated the problem down to the plugin, I would recommend to direct any feedback and problem reports to its author; even if you get a fix or workaround here, it still should flow back into the plugin.
latex-suite seems to do some kind of package scanning which I disabled by setting
let g:Tex_PackagesMenu = 0
in my .vimrc. This reduces the startup time to 3.5s (from 7s) and I think I can live with this ;).