Somehow my macvim/vim instance is expanding every tab to the autocomplete menu, this prevents me from tabbing my code.. I really dont have a clue about the why.
My vimrc is here: https://github.com/jvanbaarsen/dotfiles/blob/master/vimrc
a screenshot of the problem:
(the "happens" text, is the first appearance in the autocomplete list, i tabbed on a newline though)
I hope someone can help me, this is driving me insane!
I had found this online and used it in my vimrc to "fix" the problem. But it was still kinda a pain, so I just retrained myself to use ctrl-p. not the url in the comment was valid at one time, but is not longer..
" Remap the tab key to do autocompletion or indentation depending on the
" context (from http://www.vim.org/tips/tip.php?tip_id=102)
function! InsertTabWrapper()
let col = col('.') - 1
if !col || getline('.')[col - 1] !~ '\k'
return "\<tab>"
else
return "\<c-p>"
endif
endfunction
inoremap <silent> <tab> <c-r>=InsertTabWrapper()<cr>
inoremap <s-tab> <c-n>
I think i found the problem, it was the 'ervandew/supertab' bundle, after removing it, i was able to use vim normally.
The supertab plugin aims at both keeping usual indentation functionality of <Tab> key and completing with it. I personally don’t use it using self-written function instead, but possible causes of your issue are described in the very first question in the FAQ placed in the README file available right at project homepage:
Why isn't supertab honoring my configured settings (attempts to complete at the start of a line, always performs keyword completion instead of my configured default, etc.)?
Chances are that you have a very old version of snipmate installed, or something similar, which will issue a <c-n> when no snippet is found. Supertab use to map to <c-n>, so this behavior would act as a fallback to supertab, but current versions of supertab no longer do so, resulting in snipmate bypassing supertab entirely.
You can check if this is the case by running the following in vim to see what is mapped to <tab>:
:verbose imap <tab>
To resolve the issue you can either:
Install my fork or
Upgrade to a more recent snipmate fork, like garbase/vim-snipmate
See #74 for additional details.
Related
In my after.vim config I have line:
inoremap <S-Tab> <C-d>
I would like this binding to work. However, after starting VIM I type the first line and get the following output:
:verbose map <S-Tab>
s <S-Tab> * <Esc>i<Right><C-R>=BackwardsSnippet()<CR>
Last set from ~/dotvim/bundle/snipmate.vim/after/plugin/snipMate.vim
So snipmate is overwriting the mapping. I understand I could change it within the /bundle/snipmate.vim/after/plugin/snipMate.vim file, but that seems really ugly because I've got /bundle in my .gitignore, which seems to be standard practice.
Any ideas on how to override this, or prevent snipmate from binding to <S-Tab> ?
To remap the command executed by <S-Tab> to <C-d> add the following line to your .vimrc
imap <C-d> <Plug>snipMateBack
The snipmate documentation states you should remap <Plug>snipMateBack in your ~/.vimrc. See :h SnipMate-mappings.
Generally using a vim distribution (which you are) is considered bad for new vimmers because it disrupts learning Vim and puts up barriers when a user decides to customize (as you see here). Personally I would suggest you lose the distribution. Go find a nice plugin manager like pathogen and install plugins when you need them. Doing this means you grow your understanding of Vim as you customize it.
If really do want to use a distribution then you should first try submitting an issue to your distributions issue tracker.
In my .vimrc I have the following:
" Use j/k to navigate the word completion popup menu
inoremap <expr> j pumvisible() ? "\<C-N>" : "j"
inoremap <expr> k pumvisible() ? "\<C-P>" : "k"
This works perfect when using vim within a terminal, however this is not compatible with vrapper (eclipse vim plugin). Vrapper completely stops working when these settings are in my .vimrc. In my home directory I have a .vrapperrc file, which is simply a symobolic link pointing to my .vimrc file. Hence the vim settings which are loaded for vim / vrapper are equal.
Is there a way that in my .vimrc I can detect that the settings are loaded for vrapper instead of default (terminal) vim. That way I would like to disable these settings for vrapper and just load them when vim is used from the command line. Perhaps there is a different smart way to solve this issue. Of course I could create two .vimrc files, one for default vim and one for vrapper, however that way I would need to maintain two files which I would like to prevent.
I had a similar problem in which Vrapper executed the contents of my functions immediately because it didn't understand what they were.
I solved it by wrapping the vim only code with
if has("eval")
" vim only code
endif
which caused Vrapper to ignore it.
As #romainl noted, Vrapper only understands a limited set of Vim commands and features. Function definitions, ternaries and <expr> are definately not supported.
If you are willing to split your rc files, you could use the source command to at least reuse one of them.
For example, put these basic settings in your .vrapperrc:
set ignorecase
set hlsearch
Then you can do this in your .vimrc:
" Load common settings for Vim / Vrapper
source .vrapperrc
" ... Other Vim-specific settings
Note that Vrapper also has a source command, so you could in theory have 3 rc files with the "common" settings shared between the two:
Example .vrapperrc:
set novisualmouse
source .vimcommonrc
Example .vimrc
" Use j/k to naviage the word completion popup menu
inoremap <expr> j pumvisible() ? "\<C-N>" : "j"
inoremap <expr> k pumvisible() ? "\<C-P>" : "k"
source .vimcommonrc
And the common settings:
set hlsearch
set ignorecase
It's your choice.
I don't think you can detect Vrapper, but you can instead write a command that real Vim will process and Vrapper will ignore.
Example: mapping <KMinus>:
nnoremap <KMinus> q
If Vrapper runs that, it crashes. Let's make it ignore it. There are many ways:
if v:true
nnoremap <KMinus> q
endif
if v:true | nnoremap <KMinus> q | endif
exec 'nnoremap <KMinus> q'
There's also this more "aggressive" version, if the other ones don't work. It's useful for multiple commands:
if v:true |
\nmap <C-Bslash> gcc |
\vmap <C-Bslash> gc |
\imap <C-Bslash> <C-o><C-Bslash> |
\endif
You can even add a finish statement which Vim will treat as "I should stop reading this file" and Vrapper will probably ignore and keep executing the file, making it ideal to precede Vrapper-only commands:
if v:true
" Vim-only stuff
finish
endif
" Vrapper-only stuff
How do you think it would work?
Your ~/.vimrc is not a sentient being that can take decisions by itself: it needs to be sourced by a program that understands it and… that program is Vim.
Vrapper only supports a subset of Vim's vocabulary so it is not very reasonable to expect it to behave exactly like Vim. The main missing feature that would make possible the detection you are asking about is vimscript: since Vrapper doesn't support it you can't use an if-else-endif construction!
Because the two programs support vastly different sets of options and commands I'm afraid you will have to manage two separate files.
Did you try Vrapper's :source command?
When I leave insert mode by pressing Esc, there is a half-second pause before Vim actually returns to normal mode.
Normally this wouldn't be an issue, since pressing a normal mode command like j after pressing Esc executes the normal-mode command immediately (without the above-mentioned wait), but I have the mapping inoremap <Esc> <Esc>:w<CR>, so that every time I leave insert mode the file is written. I would like the write to occur immediately when I press Esc, but instead there is that half-second pause.
I'm assuming that the pause is because Vim is waiting for more input before it decides that I just meant to type a single, simple Esc. This must be because there is a mapping somewhere who's first character is <Esc>, but I've looked in my .vimrc and there is no such mapping.
Furthermore, I even ran :map <Esc>, and it returned No such mapping. So, if there is no such mapping, why does Vim appear to be waiting for more input, and how can I avoid that behavior?
Extra Information
It appears that this is not reproduceable, so here is some more information in case anyone really wants to get to the bottom of this:
I am using Steve Francia's spf13 distribution of Vim, with my own .vimrc.local on top of it. I have also installed several additional plugins using Vundle.
Notes: .vimrc.local is sourced last in .vimrc.
UPDATE (3/19/2014)
I found a far better solution than trying to hunt down all the mappings that start with <Esc>, courtesy of Powerline, from the Tips & Tricks section of the docs. Put this somewhere in your .vimrc:
" leave insert mode quickly
if ! has('gui_running')
set ttimeoutlen=10
augroup FastEscape
autocmd!
au InsertEnter * set timeoutlen=0
au InsertLeave * set timeoutlen=1000
augroup END
endif
Note that this will make it impossible to use mappings that start with <Esc> while in insert mode, but there shouldn't be any of those anyway, because of the problem this solves.
I found the lines in spf13's .vimrc that were causing the problem:
" Fix home and end keybindings for screen, particularly on mac
" - for some reason this fixes the arrow keys too. huh.
map ^[F $
imap ^[F $
map ^[H g0
imap ^[H g0
The reason I couldn't find them before is because they weren't mapped using <Esc>, but ^[ instead. Very irritating! Hope this helps some equally disgruntled spf13 user :)
UPDATE:
If removing those mappings doesn't work, then it's probably a mapping from a plugin.
Type :verbose map <Esc> to get a list of all mappings involving Esc. The verbose part instructs Vim to print where the mapping was set. That should help find out what's causing the problem.
Also, the command unmap <Esc> might be useful—it removes any mappings for the Esc key.
Note that unmap does not remove mappings in all modes; type :h unmap for more info.
In my case, it was tmux injecting that delay (this came as a complete surprise for me!).
I fixed it by adding set -g escape-time 0 to my tmux.conf.
This may not strictly help the author, but this question comes up first when searching for this issue with many different keyword combinations, so I hope it helps someone.
Source: first comment from here.
I'm not exactly sure what the problem is with the mapping you describe, in my opinion it should be fine. However, I think that what you want to accomplish can be reached in a better way. Your mapping is basically an attempt at creating a InsertLeave event, which Vim actually already has built in!
Try adding something like this to your .vimrc:
au InsertLeave * if &mod && expand('%')!=''|write|endif
As an added bonus, this one only saves your buffer if it has a filename and was actually modified.
set timeoutlen=1000 ttimeoutlen=0
timeoutlen - mapping delays.
ttimeoutlen - key code delays.
Source
After installing vim-ruby-debugger that plugin "hijacks" several mappings. Like <leader>n, or <leader>t which I use for respectively NERDTreeToggle and Command-T find.
The culprit is found at the hardcoded mappings in this ruby-debugger.
I'd prefer to have these remapped as <leader>rdX, i.e.: prefixed with *r*uby-*d*ebugger. Obviously, I could simply hack the plugin and change the mappings there. But that seems a bit too hackish (and will probably break on updates).
How can I unmap these mappings, so vim will fallback to my own mappings again? And so that I can remap the commands in my .vimrc (where it should be, IMHO).
First, I agree with ZyX's comments that this is a problem in the plugin that should be fixed. Please ask the plugin author to provide customization.
There is no easy way to unmap, because Vim does not remember the original mappings when a mapping is overridden. You have to make a note of the original mappings (:map ... when the offending plugin is temporarily disabled, or look in the Vim script for their definitions), then re-execute them after the offending plugin has been loaded (minus any <unique> flags it may have, as these will cause errors on re-execution). This cannot be done in .vimrc, it is sourced first; I would recommend a place like ~/.vim/after/plugin/zzzmappings.vim for this.
I keep all of my mappings in after/plugin/keys.vim. This seems to ensure that they always take precedence over plugin mappings. (I use a bunch of plugins, and the collisions seem taken care of) (here's my nvim config)
FWIW, I also keep filetype-specific mappings in the same folder, but write them as autocmd FileType commands with the <buffer> keyword. For example, the following is a mapping that conflicts with bullets.vim's ToggleCheckbox function (it adds an empty checkbox to the bullet if there is none)
autocmd FileType markdown nnoremap <buffer> <expr> <leader>x (getline('.') =~ '^\s*- \[' ? ':ToggleCheckbox<cr>' : '0/-<space><cr>la[<space>]<space><esc>')
I'm on this computer (ubuntu) where TAB is mapped (I can't find where) to autocomplete. I searched and seems like this is done by supertab, although I couldn't find how to disable it, neither did I find its files.
In my ~/.vimrc and /usr/share/vim/vimrc files, there is no mapping of the tab key. The later file includes debian.vim (and tries with /etc/vim/vimrc.local, but that doesn't exist) but that also doesn't have any mappings of tab, or any reference to supertab.
The output of :map! is this:
i <S-Tab> * <C-R>=BackwardsSnippet()<CR>
i <Plug>SuperTabBackward & <C-R>=<SNR>13_SuperTab('p')<CR>
i <Plug>SuperTabForward & <C-R>=<SNR>13_SuperTab('n')<CR>
i <C-Tab> * <Tab>
i <Tab> * <C-R>=TriggerSnippet()<CR>
i <CR> * <C-R>=<SNR>13_SelectCompletion(1)<CR>
i <C-N> <Plug>SuperTabForward
i <C-P> <Plug>SuperTabBackward
i <C-R><Tab> * <C-R>=ShowAvailableSnips()<CR>
i <C-X> <C-R>=<SNR>13_ManualCompletionEnter()<CR>
Which indicates that supertab is indeed mapping these keys.
I tried putting nomap! <TAB> in my ~/.vimrc, but it doesn't work as it seems like supertab is being loaded after ~/.vimrc is read.
My question is, how can I disable supertab, or alternatively make sure ViM doesn't let anyone map TAB to anything else?
Supertab is a plugin. As such it should be installed somewhere in ~/.vim/. There are many ways to install plugins (default, pathogen, vundle, etc.). Look into ~/.vim/bundle (if you use Pathogen) or in ~/.vim/plugin.
If it's not there it may have been installed in /usr/share/vim/vim7x/ which is very crowded and should not be touched in any way: good luck.
Anyway, you can do :verbose map! to see where the mappings are set (and thus, where the plugin is installed if you want to remove it) or you could simply configure Supertab to not use <tab>. See :help supertab.
In case you don't want to completely get rid of supertab you can remap the default keybindings using something like (in your ~/.vimrc):
let g:SuperTabMappingForward = '<c-space>'
let g:SuperTabMappingBackward = '<s-c-space>'
If you only want to insert literal tab characters, supertab makes it easy by mapping literal tabs to ctrl+tab by default (which unfortunately doesn't work in terminal). It can be customized by using something like:
g:SuperTabMappingTabLiteral='<C-`>'
Lastly, you can always escape a mapping by prepending it with ctrl-v in insert mode.
see :h supertab-forwardbackward for more information. (might not work if you haven't built supertab docs)