I am writing a vim script which may need to map the key to trigger a function, but it looks like whatever I write in the imap command, the mapping is not worked.
For testing purpose , I set map the to like:
imap <Space> <Esc>
So I should escape from the insert mode when I press a space.But it seems not working... Is it possible to imap in vim? If not, I will find another way to work around.
It's so strange to answer my own question , but I found a solution after all. mapping-enter-key-in-vim In this question, the answer is
inoremap <buffer> <Space> <esc>
Another problem is that AutoPairs is overriding setting.... So my setting is not working.
Related
I've added the following configuration to my init.vim file (I'm using neovim):
imap <leader>aa <Esc> :w!<CR>
My <leader> has been mapped to space.
The goal is to hit SPC aa when in insert mode and I will exit insert mode and then force write the file.
This documentation makes it seem like having a sequence of commands should work just fine with imap. I have other multicommand shortcuts in my init.vim that work just fine too, for example nnoremap <leader>so :source $MYVIMRC<CR>.
When I execute the imap <leader>aa <Esc> :w!<CR> shortcut all that happens is that I exit insert mode. The changes are not forced written. This implies that only <ESC> is being executed.
Is there something wrong with my configuration?
ANSWER FOUND
This mapping:
imap <leader>aa <Esc> :w!<CR>
will not work because of the space between <Esc> and :w!<CR>. If you remove the space, it will work. So the mapping:
imap <leader>aa <Esc>:w!<CR>
will work.
I started using Vim recently, just installed NERDTree (a plugin to navigate files).
The command to access that plugin is :NERDTree so I though it's a good idea to start learning mappings by assigning one to that command.
So I added to my .vimrc file the following line: map :nt :NERDTree - but when I type :nt in a vim file (even after restarting) I receive the following error message: not an editor command: nt
I also tried to add the mapping directly while editing a file by typing :map :nt :NERDTree but it returned the same error when I tried to use the command.
I checked that answer:What is the difference between the remap, noremap, nnoremap and vnoremap mapping commands in vim?, so it seems to me that :map (opposed to noremap etc.) is the good command for that.
The plugin works fine when typing the original command.
What am I doing wrong? (sorry for the noob question)
:NERDTree is a command, not a mapping, so there's no reason for creating a recursive mapping, here.
:map is too overreaching. You should use :<mode>map (for recursive mappings) or :<mode>noremap (for nn-recursive mappings).
You are missing a <CR> at the end of your mapping to tell Vim to actually execute the :NERDTree command.
In this specific case, the right mapping would be:
nnoremap :tn :NERDTree<CR>
But mapping something to :<anything> is not a good idea because it will introduce a timeout whenever you try to execute an Ex command. This means that you need to find another combo. Why not <Space>n?
nnoremap <Space>n :NERDTree<CR>
With the mapping that you have, it will be require multiple keystroke. Will it be okay for you to use a single key like F2?
nnoremap <F2> :NERDTreeToggle<CR>
This will toggle open/close NERDTree upon pressing F2 and save you some key stroke.
Here
you can figure out, how vim's mapping work and look like ;). Don't forget to source your new .vimrc before using.
I'm working on a plugin to allow bracket completion (I know it's available, it's more of a learning exercise). To properly implement it, I need to add to the backspace mapping. However, as it's an important key, I'd rather keep the existing functionality and just add to it rather than reimplementing the functionality. The steps would basically be when in insert mode and press backspace, execute the original backspace key, then check for some conditions and maybe remove more characters.
I've tried something like imap <backspace> <backspace><call_func_here>, but that doesn't seem to work. Again, I know I could remap backspace to just the function and try to recreate the backspace functionality, but I'd prefer to not do that.
Is this possible in vim?
I think what you are trying to do is the following:
inoremap <silent> <BS> <BS><C-o>:call MyFunction()<CR>
inoremap allows to create a non recurrent mapping in insert mode (it is often a good idea to use nore in your mappings). :h :inoremap
<silent> precise that the mapping will not be echoed on the command line (You will not see :call MyFunction() in the command line) :h :map-silent
<BS> is the reference to the backspace key that you want to remap.
The second <BS> is here to issue a backspace in insert mode
<C-o> switches to normal mode for only a command. :h i_CTRL-O
:call MyFunction() is the call to your function the way you would do it in normal mode.
<CR> correspond to the Enter key which validate the call to your function.
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
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