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?
Related
So here is my mapping:
nnoremap <cr> :nnoremap <lt>cr> :w!<lt>cr>:!tmux send-keys -t :1.1 "py.test --cov=." C-m <lt>cr><lt>cr><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left><left>
It's pretty awesome. What it does is when I first start my vim session (or after reloading a vimrc), and hit enter, I can immediately type the name of the tmux session that I'm in and hit enter again. Assuming that I'm editing my files in the zeroth pane of window 1 and I have a tmux split (horizontal, in my typical case). Subsequent times hitting enter in normal mode will save my active file and launch my py.test tests in another window. That means that I can technically continue coding before my tests have finished passing. I forget who I first got the idea from, but h/t that guy.
Anyhow, you've no doubt noticed that there are a lot of <left>'s in that mapping, because I'd like to start the command out being able to set the session name. But there also might be cases where I'm editing my code in a different window or something, or I need to change my pytest command or something, so I still want the ability to make those modifications.
Is there a way that I can improve this mapping? Maybe by approaching it in a different way altogether?
Your initial mapping builds another mapping command, and uses <Left> to insert the cursor on the right position to complete and then execute it.
An alternative to that would be defining a custom command (e.g. :TestInSession) that takes the variable parts as argument(s). Then, your initial mapping could just build the other mapping, leaving the cursor at the end of :TestInSession, and you would have less clutter in the command-line, and easier editing at the end.
If you need the ability to re-configure your other mapping, you could define an alternative initial mapping that isn't overwritten, e.g.:
:nnoremap <Leader><cr> :nnoremap <lt>cr> ...
I am working with vim on debian.
When I press ctrl-] vim beeps, inserts a new line and goes to "visual block". It does not jump to tag. The same happens with :ctrl-]. Even in insert-mode with ctrl-] vim exits from insert-mode, insert new line and goes to 'visual block'.
But when I use such lines in .vimrc
nnoremap <F3> <c-]>
vnoremap <F3> <c-]>
jumping with F3 works.
Command :verbose map c-] returns No mapping found
update:
As we have discovered in insert mode we can see how vim is interpreting <c-]>. In insert mode after <c-V><c-]> the correct output should be ^] . But my output is
t
^C
Screenshots: after <c-v> I get
And after <c-v><c-]> .
So vim isn't receiving the keystrokes properly. How to check what changes input?
try running vim -u NONE to check if that's happening without any configuration, that way you can be sure it's not a mapping or misconfiguration.
if that solves the issue, check your vim configuration!
Also try doing it in gvim and gvim -u NONE to narrow down the issue to what it's very likely to be. If that works it's a shell or terminal misconfiguration.
if it still fails in the windowed GUI of vim, that means this is X that is wrong, try using xev to see what your key outputs, and xmodmap to printout the values assigned to all your keys on your keyboard layout.
Try using another terminal (like urxvt, gnome-terminal, xterm or the raw linux console), to determine whether it's a terminal emulator misconfiguration of your keys or if it's your shell.
if it's your terminal emulator, then get through the configuration or reset its configuration, there's something setup that shouldn't have been.
Try changing shell to see if that improves (by I doubt it will)… And add the following configuration files in your home directory:
.inputrc
Tab: complete
set meta-flag on
set input-meta on
set output-meta on
set convert-meta off
If that's not enough, you might want to check as well you stty settings for your current shell as well.
If none of that helps, then… take a big hammer and hit very hard your keyboard and your computer, that won't solve your situation, but you'll feel better!
HTH
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.
<C-W><C-O> or <C-W>o invoke the vim single-window command which maximizes the current vim split, and annoyingly (if you keep typing it by accident) closes all others.
I want to remap it to <C-W><C-_> which doesn't close other windows.
In .vimrc I have
map <c-w><c-o> <c-w><c-_>
map <c-w>o <c-w><c-_>
This works if I type C-W and then o or C-O in quick succession.
However, if I type C-W, then wait a second, and then type o or C-O the mappings I have set up are bypassed, and the single-window command is invoked.
Should I use some other map variation?
Another thing you can do is modify the 'timeout' and 'timeoutlen' settings:
For example :set timeoutlen=3000 will set the mapping timeout to 3 seconds instead of 1 (default).
Reference on :help 'timeout' and :help 'timeoutlen'.
The difference between mappings and the built-in two-key mappings like <C-w>o is that the former timeout, whereas the latter wait indefinitely for the second key press. To completely override the behavior with a mapping, you'd have to define an (expression-) mapping for <C-w>, and handle the second key inside the mapping with getchar() (which also waits indefinitely).
But please think carefully whether such effort is really needed: If you're prone to fat-fingering keys or pressing the wrong ones, your use of Vim will be severely hampered. Better learn through the quick feedback that you've pressed something wrong, and try to work on improving your muscle memory!
How about putting set hidden into your .vimrc, so after closing all the splits they don't get closed, only put to background? After that you can list all the opened buffers via :ls command for example.
But regards to your mapping, maybe you could try unmapping (or yet even better nunmap - which unmaps a command only in normal mode) o first, and then map it.
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.