Is there a way to unmap mappings set by plugins? I'm currently calling exe ":mapclear" before my custom mappings in my .vimrc file, but the plugin files appear to be sourced after the vimrc file does. I have to resource my vimrc file again for it to work as expected.
I'm using Pathogen for sourcing plugins, which are all contained in my ~/.vim/bundle folder.
You could write the part with the mappings in your .vimrc in another file, say MyMaps.vim, and put this file in ~/.vim/after/plugin/.
This should make your maps the default ones
Look also at the documentation of the plugins setting the mappings, some of them
allow you redifine or deactivate the default mappings.
While snooping around my various plugins, I've found a kind of solution.
Unfortunately, a lot of the plugins (such as vim-surround, and vim-align, which in turn uses cecutil) add commands to my mapleader. Since I realised there actually are some key mappings from plugins I do use, I decided to set my mapleader back to its default (backslash) at the end of my vimrc file to prevent overlap.
The only problem I came across were mappings that were set in functions. When using au FileType html call ConfigHTML(), for example, the ConfigHTML() function would actually get called after the mapleader is set back to backslash.
Related
Gvim is behaving weird and I can't find the reason. I use Vundle, and all the plugins declared in my .vimrc are working fine. I declared some additional settings and plugins in .vim/after/ftplugin/java.vim.
The mappings work fine, but the plugins do not work. If I choose a different file in my current gvim session, I get those error messages:
Error detected while processing function vundle#config#bundle[2]..<SNR>14_check_bundle_name:
line 2:
Vundle error: Name collision for Plugin Raimondi/delimitMate. Plugin Raimondi/delimitMate previously used the name "delimitMate". Skipping Plugin Raimondi/delimitMate.
Vundle error: Name collision for Plugin artur-shaik/vim-javacomplete2...
[comment: same error message for all plugins declared in the ftplugin]
I noticed, that if I run :VundleInstall the plugins are suddenly working (the error messages stay when I change the file, no plugins are installed when I use the command).
Here is the beginning of my .vimrc:
syntax on
set guifont=Inconsolata\ Medium\ 12
set nocompatible
set t_Co=256
filetype off
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
" let Vundle manage Vundle, required
Plugin 'VundleVim/Vundle.vim'
"[comment: all plugins I use for every filetype]
call vundle#end() " required
filetype plugin indent on
and this is my java.vim file:
filetype off
"to automatically close brackets
Plugin 'Raimondi/delimitMate'
"omni-complete for Java
Plugin 'artur-shaik/vim-javacomplete2'
"use tab to navigate through insert completion
Plugin 'ervandew/supertab'
filetype plugin indent on
"needed to make javacomplete2 working properly
autocmd FileType java setlocal omnifunc=javacomplete#Complete
My OS is Ubuntu 16.04.
You're mistaken regarding what ftplugins are doing and what they should contain.
Ftplugins are loaded once per buffer, every time a new buffer is created/opened.
They are meant to contain buffer local definitions:
:map <buffer> keybinding action
:iab <buffer> keybinding expanded sequence
:setlocal option[=value]
:command -b CommandName :Action
:let b:option = value
set the localleader (but be certain it's done before any other ftplugin for the same filetype) (EDIT: localleader is actually a global setting, my mistake)
They could then load other things that work the same way with :runtime or :so. They could contain functions, but it's best to define them into autoload plugins since Vim7. They may contain buffer local menu definitions, but this requires a plugin as this is not standard.
They are definitively not meant to contain global definition like the ones you have defined. It's not really the place to load global plugins that'll stay activated afterwards.
I know that some plugins manager load plugins on the fly depending on the type of the file we work on. I've never shared this need when we are using properly defined ftplugins, and lightweight plugins that only define a few mappings and keep their functions into autoload plugins.
Last thing, ftplugins are supposed to contain anti reinclusion guards. On a typical scenario this is not that useful. Many use b:did_ftplugin for that purpose, but I avoid this variable as I prefer to have as many ftplugins (for a same filetype) as themes (one that specializes the brackets pairs, one that defines the mapping to automatically expand a switch statement from the type of a variable, one that defines abbreviations for control statements, and so on). As a consequence I cannot use the same guard for all files.
All your :Plugin commands are supposed to be between these two lines:
call vundle#begin()
" :Plugin commands go here
call vundle#end()
Try another plugin manager if you absolutely need lazy loading.
So I just installed vim-colors-solarized (using Pathogen), and discovered in the documentation that it features a script called togglebg.vim that maps <F5> to a function to toggle the background between light and dark – but I can't work out how to enable the mapping when vim starts up.
This script is located under ~/.vim/bundle/vim-colors-solarized/autoload. (I did some reading and think I understand how autoload folders work.) It contains the following function call, which maps <F5> as mentioned above:
if !exists("no_plugin_maps") && !hasmapto('<Plug>ToggleBackground')
call togglebg#map("<F5>")
endif
Since it's in an autoload folder, vim does not source the script until something else (e.g., .vimrc) calls one of its functions. Thus, the code above is not sufficient to invoke the keymapping, because it is contained within the script itself.
I know there are ways to source the script:
Renaming the script's parent directory from autoload to plugin will force vim to source it on startup.
Adding a line to .vimrc with a call to togglebg#map() will also force vim to autoload the script.
But none of this is mentioned in the documentation, which was most certainly written by people who understand vim way better than I do. All the documentation says is this:
Solarized comes with Toggle Background, a simple plugin to switch between light and dark background modes and reset the colorscheme. This is most useful for colorschemes that support both light and dark modes and in terminals or gui vim windows where the background will be properly set.
Toggle Background can be accessed by:
...
* the default mapping of <F5>
...
Toggle Background starts with a default mapping to function key <F5>. If you
are already using this in a mapping, Toggle Background will not map itself to
a default and you will have to map it manually in your .vimrc file, or
remove/change your existing <F5> mapping to another value. To customize the
keyboard mapping in your .vimrc file, use the following line, changing the
<F5> value to the key or key combination you wish to use:
call togglebg#map("<F5>")
That last line implies that I only need to call togglebg#map() if I want to map the togglebg function to a key other than <F5>, and that the <F5> keybinding should be available on installation without any further mussing and fussing.
So what am I missing here? Is there a "proper" way to source this script and enable the 'default' <F5> mapping? Could it be that somebody moves the files around in the repo and forgot to update the documentation, or vice versa? Or am I supposed to suck it up and just make a function call from .vimrc?
EDIT
It's working all of a sudden. I don't know what I changed in my .vimrc file, if anything, but it definitely wasn't working at work yesterday (gVim on Windows), and it's definitely working at home now (also gVim on Windows, vimfiles folder synced via Dropbox).
But maybe I can amend this question: If this functionality is supposed to be available by default, why is the script placed in an autoload folder?
I use Pathogen to load my plugins at startup.
Sometimes I use Neocomplete plugin, sometimes YouCompleteMe plugin and sometimes Supertab to complete words and sometimes I use no completer at all.
These plugins do not work together if they are all loaded in Pathogen.
That's why I decided to create a little menu at then end of my vimrc where I can chose which completer to use (the one that I want to use is the one I disable in pathogen). I can launch it with a shortcut key.
The list g:PATHO contains the plugins to disable in pathogen:
If I chose to use Supertab --> remove Supertab from g:PATHO, save g:PATHO and reload vimrc.
If I chose to use Neocomplete --> remove Neocomplete from g:PATHO, save g:PATHO and reload vimrc.
If I chose to use Youcompleteme --> remove Youcompleteme from g:PATHO, save g:PATHO and reload vimrc.
This is what I have at the start of my _vimrc
if !exists("g:PATHO")
let g:PATHO = ['YouCompleteMe','neocomplete.vim','supertab']
endif
let g:pathogen_disabled = g:PATHO
below in my _vimrc I have this command to save global variables in my viminfo file:
set viminfo+=!
(thanks to Ingo Karkat)
g:PATHO is written in viminfo but when I reload vimrc, the variable g:PATHO is not found because viminfo is not yet read at the start of _vimrc.
When is viminfo read in _vimrc?
How can I let pathogen read g:PATHO at vimrc startup?
(hope I made myself clear)
Did you read :help startup?
Your viminfo file is read very late in the initialization process, after your vimrc and all your plugins are sourced, so pathogen won't be able to compare the default g:PATHO that you hardcoded in your vimrc with the one in your viminfo.
Your viminfo file is read only once, late in the initialization process, and will never be re-read again during the life span of your session. Reloading your vimrc will never trigger that re-read and neither pathogen nor any other plugin will notice the change you hoped to persist.
You can try :rviminfo to re-read that file manually and autocmds on VimEnter or some other event but…
…modifying the g:pathogen_disabled variable during a session won't have the effect you want: it doesn't remove a plugin from your runtimepath and it doesn't "unsource" it either. You can reload your vimrc all you want with different values for that option, the result will always be the same: nothing.
What you need — beyond coming up with a convincing justification for such a weird idea or even for the fact that you have three freaking completion plugins in your config — is to find a way to effectively make the functions and variables and whatever of a specific plugin completely disappear from Vim's memory. And I believe you won't find it here.
As a side note, only one of the three plugins provides built-in commands to enable/disable it. That is a sensible design choice that, if it was more universally available, would make the life of plugin hoarders a lot easier.
For example https://www.ffmpeg.org/developer.html#Editor-configuration requires specific set of rules, but for my projects I usually prefer different one.
It would be great to have several named groups of formatting options for different projects and switching between them easily without modifying .vimrc
Vim does not have a concept of project so it has no native way to do such a thing. But don't let that get you down. We can still accomplish such a goal.
set exrc
set exrc
This enables the reading of .vimrc, .exrc and .gvimrc in the current directory. However this means you must open vim with the correct current working directory and opening another project in the same vim instance will not switch your settings. See :h 'exrc' for more information.
Roll your own autocommands
Vim's autocommands are basically event handlers. You can handle an event like opening a buffer from a specific directory and run a command, like sourcing some config settings.
augroup ProjectSettings
autocmd!
autocmd BufRead /project1/* source ~/.vim/project1_settings.vim
autocmd BufRead /project2/* source ~/.vim/project2_settings.vim
augroup END
As long as your settings files use buffer local setting commands like setlocal and mappings/abbreviations with the <buffer> option, your settings will be applied to just the buffers in your project.
I believe one (maybe?) of Derek Wyatt's vim videos show a similar method to this.
See the following for more information:
:h :au
:h BufRead
:h :so
:h :setl
:h <buffer>
Plugins
Sometimes it is just easier to use someone else solutions. There are a few local vimrc plugins out there that help give you local settings:
localvimrc
localrc.vim
vim-addon-local-vimrc
Another nice plugin option may be using Tim Pope's vim-sleuth which heuristically changes indent setting based on the file or in the case of blank/new files other files of the same type.
If project navigation is up your alley then I would suggest you look at Tim Pope's projectionist plugin or a nice fuzzy finder.
Conclusion
There are many options to explore here and no real right answer. I personally suggest using the plugin approach as it the easiest. However I feel obligated to tell you I use Projectionist and a custom project plugin for my projects at work so I am biased.
I understand that the recommended method for defining filetype-specific behavior in Vim is with .vim files and filetype plugin option. To add settings for .html files, for instance, I would add filetype plugin on in my .vimrc and add the settings to ~/.vim/ftplugin/html.vim.
All examples of this method that I can find, however, are about popular existing filetypes like .html or .sql. Would the same fix work for custom-defined file types? Let's say I want to use a new filetype with the extension .newft. If I create ~/.vim/ftplugin/newft.vim with the settings for this new type and load somefile.newft, would Vim automatically detect its type and load newft.vim?
I'm asking this because this is exactly what I'm doing and it's not working so far. I'd like to know whether this is an error or an expected behavior of Vim.
:h new-filetype outlines the different ways to add support for a new filetype.
I recommend method A which is as simple as writing the following in ~/.vim/ftdetect/newft.vim:
autocmd BufRead,BufNewFile *.newft set filetype=newft
and letting Vim deal with the rest.
Assuming you have filetype plugin on in your ~/.vimrc, the example above will make Vim try to source ~/.vim/ftplugin/newft.vim each time you read or create a buffer associated with a *.newft file or do :setfiletype newft/:set filetype=newft on an existing buffer.