Note:
This is a plugin-induced problem, but it happens with multiple plugins and it does not happen in MacVim.
Problem:
When hitting Backspace in Insert mode while using a plugin which handles automatic closing of brackets, quotes and such (delimitMate, vim-autoclose), the cursor turns into a block while deleting the character (this happens faster than I can blink my eyes but remains one of my pet peeves on terminal Vim), giving the impression of a tiny flash, which on every deletion of a character becomes annoying.
I presume it leaves Insert-mode to perform an normal/ex command), due to the remap done by the plugins, and I can confirm that this "changes to block and back"-flash does NOT happen with the plugins disabled.
The mapping for each of the plugins is as follows:
delimitMate
:verbose imap <BS> => i <BS> #<Plug>delimitMateBS
vim-autoclose:
:verbose imap <BS> => i <BS> *#<C-R>=<SNR>44_Backspace()<CR>
This problably means nothing as I'm not posting what the invoked functions actually do, it's just meant to show that Backspace is being remapped.
You're probably eager to point me to the issue tracker of each specific plugin at this point, but like mentioned earlier, this issue does not happen in MacVim. Perhaps it does, perhaps it's simply happening too fast for my eyes to see, but while using MacVim, there is absolutely no visible cursor change/flash.
Related
Lately, when using Vim in tmux over ssh, sometimes something happens where Vim starts ignoring all my mappings that start with Ctrl: for instance <C-P>, which I have bound to the CtrlP plugin. Instead, Vim runs the builtin action (in this case, moving lines upward in the file). I don't doubt that the correct keypress is reaching Vim, as it uses the correct builtin action associated with <C-P> (using :send-keys to send ctrl-p from tmux also causes the builtin <C-P> in vim to run, instead of the mapping).
All my mappings not involving the control key still work. For instance, I can do this:
nnoremap p :echo "test"<cr>, and pressing p echoes test
But then immediately after,
nnoremap <c-p> :echo "test"<cr>, and pressing CTRL-P doesn't echo test, it moves the cursor up one line.
Restarting Vim always fixes the issue, but at some point, something I do causes the problem to surface again. I've been working mostly in tmux through ssh lately, so I'm not 100% sure if either one of those are the problem (although I think I recall this happening once in Vim in tmux not over ssh), but as mentioned above, I believe using send-keys directly from tmux as a test is ensuring that vim is getting the actual ctrl-p keycode. As well, <C-V><C-P> in insert mode does actually insert ^P.
Note that although I've used ctrl-p here as an example, since it's a key I actually use a lot in practice, this applies to any control key mapping.
Is there some kind of Vim state I don't know about that's causing this to happen? Is this likely a terminal problem? What are my next steps?
In vim, Ctrl+[ acts like Esc by default. However, I would like to rebind Ctrl+[ to perform a custom action. (Specifically, to Ctrl-t because I find it more natural for [ and ] to have complementary actions for ctags.)
However, when I execute the command:
:nnoremap <C-[> <C-t>
then my arrow key navigation get messed up. I'm not sure what happens, but clearly that's not the ideal way to do it.
I've tried to unbind Ctrl+[ but vim reports that it wasn't bound, and I've tried some tricks like first binding Ctrl+[ to itself and then unbinding. Always the same result.
Side note: Interestingly, when I add it to my .vimrc (as the last command) it's even worse. Something nondeterministic happens and vim opens randomly in one of these 3 states:
The bottom status line says "E73: tag stack empty", implying it received a Ctrl+t-esque command, however the if I hit a nav key like j, it deletes the current and bottom line and then puts me into insert mode. (Happens ~70% of the time.)
Sometimes it's in replace mode. (Happens ~15% of the time.)
Sometimes it's in normal mode. (Happens ~15% of the time.)
How can I properly remap Ctrl+[ to a different function in .vimrc?
You can't rebind Ctrl[. Pressing the Escape key in a terminal sends Ctrl[, just like pressing the Tab key sends CtrlI. There's no separate Esc code.
Vim is probably acting crazily when you try this because basically every ANSI key sequence starts with Ctrl[, so your rebinding is firing on all terminal input, and whatever else is in the key sequence looks like more commands to vim.
Due to the way that the keyboard input is handled internally, this unfortunately isn't generally possible today, even in GVIM. Some key combinations, like Ctrl + non-alphabetic cannot be mapped, and Ctrl + letter vs. Ctrl + Shift + letter cannot be distinguished. (Unless your terminal sends a distinct termcap code for it, which most don't.) In insert or command-line mode, try typing the key combination. If nothing happens / is inserted, you cannot use that key combination. This also applies to <Tab> / <C-I>, <CR> / <C-M> / <Esc> / <C-[> etc. (Only exception is <BS> / <C-H>.) This is a known pain point, and the subject of various discussions on vim_dev and the #vim IRC channel.
Some people (foremost Paul LeoNerd Evans) want to fix that (even for console Vim in terminals that support this), and have floated various proposals, cp. http://groups.google.com/group/vim_dev/browse_thread/thread/626e83fa4588b32a/bfbcb22f37a8a1f8
But as of today, no patches or volunteers have yet come forward, though many have expressed a desire to have this in a future Vim 8 major release.
In insert mode, the command CTRL-] expands an abbreviation without entering a space. So if you set :abbrev foo bar, typing foo<C-]> will change foo to bar.
But what happens if you type bar<C-]> when you have not set any abbreviations for bar?
In one version of vim (7.3.754), the CTRL-] is ignored. In other versions that I have access to (7.3.0 and 7.2.411), a literal character ^] is inserted, so you get bar^].
Is this a bug that was fixed? Or is the different treatment because of different compiling options? And is there a way to avoid inserting extraneous ^]s when I must work in these older vims?
As discussed in the comments, the behavior changed in 7.3.489, which fixed a related bug that prevented <C-]> from expanding an abbreviation if the <C-]> was inserted via a mapping.
Funny enough, the reason I came across this was because I was defining a mapping
inoremap <CR> <C-]><CR><C-U>g
The last three characters simply create a new undo point after each <CR> pressed in insert mode. Under normal circumstances, pressing enter will also expand an abbreviation if applicable, but not if <CR> has been remapped. The <C-]> was to forcibly expand abbreviations. It turns out this is the exact mapping that led Yichao Zhou to write the above bugfix.
It isn't a perfect workaround, but by using if has("patch489") when defining the map, you can at least degrade gracefully to older versions of vim. Pressing enter will not expand abbreviations, but at least it won't insert <C-]>.
These disappear if I do a page-up and page-down. Why does this happen and how do I rectify it?
http://i.stack.imgur.com/DnMYl.png
I recently fiddled around with my vimrc. Could that be the cause?
UPDATE:
I figured out the cause. I had added to functions that automatically updated the cwd name and the current git branch in my vim statusline. This caused vim to be laggy and everytime it lagged on a up/down/left/right key hit, it printed out the ghost characters ^[OA, etc.
It's possible that stuff got complicated because I was using vim in tmux, but I saw the ghost characters outside tmux also. So, probably not.
I've turned off those two functions in my .vimrc and my vim statusline is presently less awesome than it used to be :(
Wish there's a way out.
^[OB and ^[OA are how your terminal represent <down> and <up>.
I've seen these (and their friends ^[OC and ^[OD) appear in the "command line" or omni-completion menus and during usage of a couple of plugins in vim in tmux.
My solution was to map them to the directional keys:
map ^[OA <up>
map ^[OB <down>
map ^[OC <right>
map ^[OD <left>
In case you don't know, you must not type ^[ as two characters, you must do <C-v><Esc>.
That is, while in --INSERT-- mode press the Control key and the V key together then hit the Escape key. Doing so will input the correct single character that looks like ^[.
This issue is discussed at length on the Vim Wiki article. There seem to be multiple causes, I personally encountered this issue when running vim under tmux.
A solution from there that worked for me and seems less hacky than mapping the keys was the following config:
set term=cons25
Hard to say without knowing what's in your vimrc, but you can confirm whether it's something in there by starting it up without running it and seeing if it still happens using the following...
vim -u NONE
Do you happen to be using zsh? I had this issue with vim + zsh/oh-my-zsh. Moving back to vanilla bash solved this issue (amongst others) that I was having with vim.
I use FuzzyFinder in VIM (cannot switch to Command-T, no Ruby support on my server). It works well, except for one issue: Whenever I hit backspace (for example, after making a typo), the entire FuzzyFinder buffer just closes.
This doesn't happen every time, only right after entering a directory. For example:
FILE>filename -- I can hit backspace just fine, and get FILE>filenam
FILE>folder/ -- if I hit backspace now, the buffer just closes. It's as if I can't navigate backwards in the hierarchy after entering a directory.
I have no idea why this happens, and it's driving me crazy. Any advice would be appreciated.
This also happens when I press Ctrl+w as it says in the fuf documentation.
I've been using FuzzyFinder for a while and never faced this problem.
Possible you have some mapping that may be interfering with FuzzyFinder. You could try :map <bs> to find out if there is any mapping on backspace key, and :10verbose map <bs> to find out where such mapping was set.
You also could try :unmap <bs> and :unmap! <bs> to remove any mappings from backspace and check if the issue still exists.
If the above doesn't solve the problem you might consider contacting the plugin author, as the issue could also be related to some other mapping, as stated on FuzzyFinder changelog, :h fuf-changelog:
- Fixed the bug that it did not work correctly when a user have mapped <C-p>
or <Down>.