In Vim, when in Visual mode, I have to press Esc twice to exit it and turn off the selection. After one press of Esc I have to wait 2 seconds for the selection to turn off.
What can I do to exit Visual mode immediately when Esc is pressed?
Executing following command helped me:
set timeoutlen=1000 ttimeoutlen=0
see: http://www.johnhawthorn.com/2012/09/vi-escape-delays/.
As Ingo explained. Just thought I would post the solution:
https://github.com/Greduan/dotfiles/blob/47f92e4db29d4ead778d877a85082b271de130ed/vim/vimrc.vim#L332-L346
Works pretty well. It's a little bit confusing for me as well, so I can't really explain, but the code explains itself pretty well.
The point is it works, it simply makes <Esc> work immediately even when on Terminal. I believe if you do have mappings set to <Esc> it'll give you time to do those as well. However I'm not sure.
EDIT
Studied a bit and I can now explain it. Basically, if you're not using a GUI (like MacVim) then when you enter insert mode the ttimeoutlen will be set to 0. Meaning that as soon as you click <Esc> that'll work. However once you're in normal mode then it'll set the ttimeoutlen to the number you prefer, letting you do mappings with <Esc>.
Perfect solution I think, since if you have mappings in insert mode it'll be using control or something like that.
EDIT 2
Here's the code:
set timeout " Do time out on mappings and others
set timeoutlen=2000 " Wait {num} ms before timing out a mapping
" When you’re pressing Escape to leave insert mode in the terminal, it will by
" default take a second or another keystroke to leave insert mode completely
" and update the statusline. This fixes that. I got this from:
" https://powerline.readthedocs.org/en/latest/tipstricks.html#vim
if !has('gui_running')
set ttimeoutlen=10
augroup FastEscape
autocmd!
au InsertEnter * set timeoutlen=0
au InsertLeave * set timeoutlen=1000
augroup END
endif
With time I've removed the condition that the GUI isn't running and it still works as far as I can tell.
A quick workaround is using <C-c> instead, but you probably want to fix the timeout on <Esc>, which is caused by a mapping that starts with <Esc>, which makes Vim wait for 'timeoutlen' to check whether the mapping is complete.
This does not necessarily need to be a "real" mapping; many terminal workarounds (e.g. to make certain keys work) advise to set up such a mapping. (Unfortunately, this is a difficult and complex issue.)
You can find the mapping via:
:verbose map <Esc>
I have no mapping bound to <ESC> globally or for Visual mode (calling :verbose vmap <ESC> gives no results) but there is still a significant delay when exiting Visual mode. Even on fresh installs with no vimrc the delay is present. Using <C-c> does exit visual mode without delay.
Since I don't like pressing <C-c> to exit any mode, I currently map <ESC> to <C-c> in visual mode. This exits visual mode using <ESC> without any delay.
:vmap <ESC> <C-c>
Or put the following line in your vimrc
vnoremap <ESC> <C-c>
This will not work if you do have global or visual mode mappings bound to <ESC>.
First try the accepted answer of adding the following to .vimrc
set timeoutlen=1000 ttimeoutlen=0
If that doesn't work check if you have any keybindings to <esc>
:imap <esc>
If you use tmux you also need:
set -sg escape-time 0
Related
I am a happy VIM user, although I admit I'm quite far from being fluent. I found this nice post:
Vim clear last search highlighting and I thought I'd become a better person if I didn't have to hammer away a random character sequence every time I did a search. Now, I'm also using the vimrc config from here:
http://amix.dk/vim/vimrc.html
and the problem I have is that when I add the line nnoremap <esc> :noh<return><esc> to it (it doesn't seem to make a difference where I put it) I get awkward behaviour when I use arrows in command mode, namely letters from A to D appear in a newline and I get switched to insert mode.
There has to be some mapping conflict but for the life of me I can't figure out where it is.
EDIT: As it follows from the answers it turns out the Ultimate vimrc part is not relevant, the mentioned nnoremap command will cause altered arrow behaviour even if it's the only vimrc entry. Changing title to a more informative one.
PS. I know I shouldn't use arrows, hopefully I'll get there one day.
The mapping
nnoremap <esc> :noh<return><esc>
will conflict with so called "grey keys" and I believe that it should be used either in GVim only or in terminal Vim by someone who does not use special keys like arrows.
From what I know (and guess) how Vim processes keys, I would say that it's impossible to do anything with this. For Vim to recognize special key all its components should go in a row, so when you press Arrow Left Vim gets the following sequence of codes:
<esc> [ D
But after your mapping Arrow Left becomes:
: n o h l <cr> <esc>
[ D
Vim sees two separate sequences and treats <esc> as a single press of Escape key, thus next two codes of Left Arrow key lose their special meaning.
So I suggest you to map :noh to some other key sequence (e.g. to one starting with <leader>, see :help mapleader; I don't recommend you to use F-keys, using them is as bad as using of arrow keys).
The cause had been explained well, but solution was not mentioned. However there is a straight one.
If you’ll tell to Vim explicitly that there are key sequences starting from <esc>[
:nnoremap <silent><esc> :noh<CR>
:nnoremap <esc>[ <esc>[
than when single <esc> will be pressed Vim will wait for a second (or different time, see :h 'timeoutlen') or for a next key (second <esc> for example) and only then replace it with :noh<CR>.
This solution preserves the ESC mapping to :nohlsearch.
The comment on this answer explaining why this is happening tells us that the root cause is the TermResponse behavior of vim. This can be compensated for by wrapping the mapping in an autocommand for the TermResponse event.
This ensures that the binding doesn't happen until after the term response is set, which prevents Esc from also sending a string like ]>1;3201;0c to vim.
Change your line in vimrc to this:
augroup no_highlight
autocmd TermResponse * nnoremap <esc> :noh<return><esc>
augroup END
The augroup commands are not strictly necessary, but they prevent multiple mappings when you reload your vimrc without quitting vim.
EDIT: If you also use a graphical vim like Gvim or Macvim, the TermResponse event will not fire. Assuming you use a single vimrc, you'll need some additional code like
if has('gui_running')
nnoremap <silent> <esc> :nohlsearch<return><esc>
else
" code from above
augroup no_highlight
autocmd TermResponse * nnoremap <esc> :noh<return><esc>
augroup END
end
Problem is that when you press an arrow terminal emits something like <Esc>OA. Vim part that supports terminal seems to use the same mapping mechanism to do the job as you are using: while nmap <Esc>OA will tell you nothing, call feedkeys("\eOA") will move one line up and call feedkeys("\eOA", 'n') will add letter A beyond current line. With your mapping being noremappable you forbid vim to use <Esc> as a part of the key. The problem is that you need remappable mapping here, but can have remappable mapping without it being recursive as well only if it starts with {lhs}, but <Esc>:noh<CR>OA is not going to work. I thought the following code will (it uses <expr> and function with side effect to make <Esc> be the first character of the actual {rhs} and still launch :noh), but in fact it does not:
function s:NoHlSearch()
nohlsearch
return "\e"
endfunction
nmap <expr> <Esc> <SID>NoHlSearch()
. I have no other idea how to solve the problem of having non-recursive remappable mapping which includes {lhs} but not at the start.
I have had good luck with this
if $TERM =~ 'xterm'
set noek
endif
nnoremap <silent> <esc> <esc>:noh<cr>
The disadvantage is that function keys can not be used in insert mode.
:h ek
In Vim, when in Visual mode, I have to press Esc twice to exit it and turn off the selection. After one press of Esc I have to wait 2 seconds for the selection to turn off.
What can I do to exit Visual mode immediately when Esc is pressed?
Executing following command helped me:
set timeoutlen=1000 ttimeoutlen=0
see: http://www.johnhawthorn.com/2012/09/vi-escape-delays/.
As Ingo explained. Just thought I would post the solution:
https://github.com/Greduan/dotfiles/blob/47f92e4db29d4ead778d877a85082b271de130ed/vim/vimrc.vim#L332-L346
Works pretty well. It's a little bit confusing for me as well, so I can't really explain, but the code explains itself pretty well.
The point is it works, it simply makes <Esc> work immediately even when on Terminal. I believe if you do have mappings set to <Esc> it'll give you time to do those as well. However I'm not sure.
EDIT
Studied a bit and I can now explain it. Basically, if you're not using a GUI (like MacVim) then when you enter insert mode the ttimeoutlen will be set to 0. Meaning that as soon as you click <Esc> that'll work. However once you're in normal mode then it'll set the ttimeoutlen to the number you prefer, letting you do mappings with <Esc>.
Perfect solution I think, since if you have mappings in insert mode it'll be using control or something like that.
EDIT 2
Here's the code:
set timeout " Do time out on mappings and others
set timeoutlen=2000 " Wait {num} ms before timing out a mapping
" When you’re pressing Escape to leave insert mode in the terminal, it will by
" default take a second or another keystroke to leave insert mode completely
" and update the statusline. This fixes that. I got this from:
" https://powerline.readthedocs.org/en/latest/tipstricks.html#vim
if !has('gui_running')
set ttimeoutlen=10
augroup FastEscape
autocmd!
au InsertEnter * set timeoutlen=0
au InsertLeave * set timeoutlen=1000
augroup END
endif
With time I've removed the condition that the GUI isn't running and it still works as far as I can tell.
A quick workaround is using <C-c> instead, but you probably want to fix the timeout on <Esc>, which is caused by a mapping that starts with <Esc>, which makes Vim wait for 'timeoutlen' to check whether the mapping is complete.
This does not necessarily need to be a "real" mapping; many terminal workarounds (e.g. to make certain keys work) advise to set up such a mapping. (Unfortunately, this is a difficult and complex issue.)
You can find the mapping via:
:verbose map <Esc>
I have no mapping bound to <ESC> globally or for Visual mode (calling :verbose vmap <ESC> gives no results) but there is still a significant delay when exiting Visual mode. Even on fresh installs with no vimrc the delay is present. Using <C-c> does exit visual mode without delay.
Since I don't like pressing <C-c> to exit any mode, I currently map <ESC> to <C-c> in visual mode. This exits visual mode using <ESC> without any delay.
:vmap <ESC> <C-c>
Or put the following line in your vimrc
vnoremap <ESC> <C-c>
This will not work if you do have global or visual mode mappings bound to <ESC>.
First try the accepted answer of adding the following to .vimrc
set timeoutlen=1000 ttimeoutlen=0
If that doesn't work check if you have any keybindings to <esc>
:imap <esc>
If you use tmux you also need:
set -sg escape-time 0
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
I am a happy VIM user, although I admit I'm quite far from being fluent. I found this nice post:
Vim clear last search highlighting and I thought I'd become a better person if I didn't have to hammer away a random character sequence every time I did a search. Now, I'm also using the vimrc config from here:
http://amix.dk/vim/vimrc.html
and the problem I have is that when I add the line nnoremap <esc> :noh<return><esc> to it (it doesn't seem to make a difference where I put it) I get awkward behaviour when I use arrows in command mode, namely letters from A to D appear in a newline and I get switched to insert mode.
There has to be some mapping conflict but for the life of me I can't figure out where it is.
EDIT: As it follows from the answers it turns out the Ultimate vimrc part is not relevant, the mentioned nnoremap command will cause altered arrow behaviour even if it's the only vimrc entry. Changing title to a more informative one.
PS. I know I shouldn't use arrows, hopefully I'll get there one day.
The mapping
nnoremap <esc> :noh<return><esc>
will conflict with so called "grey keys" and I believe that it should be used either in GVim only or in terminal Vim by someone who does not use special keys like arrows.
From what I know (and guess) how Vim processes keys, I would say that it's impossible to do anything with this. For Vim to recognize special key all its components should go in a row, so when you press Arrow Left Vim gets the following sequence of codes:
<esc> [ D
But after your mapping Arrow Left becomes:
: n o h l <cr> <esc>
[ D
Vim sees two separate sequences and treats <esc> as a single press of Escape key, thus next two codes of Left Arrow key lose their special meaning.
So I suggest you to map :noh to some other key sequence (e.g. to one starting with <leader>, see :help mapleader; I don't recommend you to use F-keys, using them is as bad as using of arrow keys).
The cause had been explained well, but solution was not mentioned. However there is a straight one.
If you’ll tell to Vim explicitly that there are key sequences starting from <esc>[
:nnoremap <silent><esc> :noh<CR>
:nnoremap <esc>[ <esc>[
than when single <esc> will be pressed Vim will wait for a second (or different time, see :h 'timeoutlen') or for a next key (second <esc> for example) and only then replace it with :noh<CR>.
This solution preserves the ESC mapping to :nohlsearch.
The comment on this answer explaining why this is happening tells us that the root cause is the TermResponse behavior of vim. This can be compensated for by wrapping the mapping in an autocommand for the TermResponse event.
This ensures that the binding doesn't happen until after the term response is set, which prevents Esc from also sending a string like ]>1;3201;0c to vim.
Change your line in vimrc to this:
augroup no_highlight
autocmd TermResponse * nnoremap <esc> :noh<return><esc>
augroup END
The augroup commands are not strictly necessary, but they prevent multiple mappings when you reload your vimrc without quitting vim.
EDIT: If you also use a graphical vim like Gvim or Macvim, the TermResponse event will not fire. Assuming you use a single vimrc, you'll need some additional code like
if has('gui_running')
nnoremap <silent> <esc> :nohlsearch<return><esc>
else
" code from above
augroup no_highlight
autocmd TermResponse * nnoremap <esc> :noh<return><esc>
augroup END
end
Problem is that when you press an arrow terminal emits something like <Esc>OA. Vim part that supports terminal seems to use the same mapping mechanism to do the job as you are using: while nmap <Esc>OA will tell you nothing, call feedkeys("\eOA") will move one line up and call feedkeys("\eOA", 'n') will add letter A beyond current line. With your mapping being noremappable you forbid vim to use <Esc> as a part of the key. The problem is that you need remappable mapping here, but can have remappable mapping without it being recursive as well only if it starts with {lhs}, but <Esc>:noh<CR>OA is not going to work. I thought the following code will (it uses <expr> and function with side effect to make <Esc> be the first character of the actual {rhs} and still launch :noh), but in fact it does not:
function s:NoHlSearch()
nohlsearch
return "\e"
endfunction
nmap <expr> <Esc> <SID>NoHlSearch()
. I have no other idea how to solve the problem of having non-recursive remappable mapping which includes {lhs} but not at the start.
I have had good luck with this
if $TERM =~ 'xterm'
set noek
endif
nnoremap <silent> <esc> <esc>:noh<cr>
The disadvantage is that function keys can not be used in insert mode.
:h ek
Background:
Sometimes when editing in vim it is possible to have extra characters in a file that the user did not expect to be there because he was in "insert mode" when in a hurry and rushing to get something finished.
Fortunately, even if the user is rushing, pressing ESC a couple of times is always sufficient to get them out of insert mode and into normal mode, with no surprises.
Question:
Is there a key binding that works the same way for insert mode? Pressing "i" can get you into insert mode, but if you press it multiple times, you will start inserting the letter "i" into the file.
Goal:
The goal is to have some key binding for getting back into insert mode that the user can even press multiple times with eyes closed, and still not worry about "surprises" of unexpected characters being put into the file.
<C-o>i should do the trick. <C-o> gets you temporarily to normal mode, but for only one command, if that command is "go to insert mode" than well, you simply return there.
Edit: I could reproduce your error message now, and it seems the easiest thing to do is this:
:nmap <C-i> i
:imap <C-i> <C-o>i
If do not map <C-i> in insert mode, but in normal mode only, then repeatedly hitting <C-i> will be idempotent.
Thanks to Benoit for mentioning that <C-i> inserts a tab in insert mode.
You should do a mapping that behaves differently in the distinct modes:
:inoremap <F1> <NOP>
:nnoremap <F1> i
:vnoremap <F1> <esc>i
:cnoremap <F1> <C-C>i
:onoremap <F1> <esc>i
Hitting F1 will go to insert mode then.
You can also toggle the 'insertmode' setting (:set insertmode): in this mode, the Insert mode is the default mode (to which you switch with Escape, and you go to normal mode with CTRL-L.
The answer given by bitmask works, but it apparently has the side-effect of producing the error message:
E37: No write since last change (add ! to override)
Unless you have configured your vimrc to turn that message off.
But another alternative that seems to work without producing error messages:
CTRL-C i
Which seems to work on standard vim.