I'm trying to switch to vim and I'm having some difficulty trying to understand what these remaps mean.
I'm using this tab plugin from https://github.com/romgrk/barbar.nvim.
In the read me file they have something to bounce from tabs with the commands as the following:
nnoremap <silent> <A-1> <Cmd>BufferGoto 1<CR>
nnoremap <silent> <A-2> <Cmd>BufferGoto 2<CR>
Can anyone enlighten me and future viewers of this thread, what these commands are and what they mean?
Thank you.
The various *map commands cause one set of keys to be replaced by another.
<A-1> and <A-2 are special key names representing Alt-1 and Alt-2, respectively (hold down the Alt key, then press 1 or 2).
<Cmd> indicates that the following text should not be used literally, but is a command that should be executed instead.
So pressing Alt+1 switches to buffer 1, and pressing Alt+2 switches to buffer 2.
Related
I want to be able to save a file in vim while in the insert mode. I thought of using the following shortcut:
inoremap <leader>w <Esc>:w<cr>
While the shortcut saves the file in the insert mode, it leaves the cursor one spot ahead of where the cursor would be if I physically typed out the keys
Esc :w followed by Enter. This is a problem because when I use the shortcut whenever I am at the end of a line, it takes me to the next line, and I have to then come back to the spot where I initiated the save.
Any help would be appreciated on how I can map <leader>w to the exact actions that occur in Vim when I physically type out the Esc :w followed by Enter key sequence.
I should add that if I instead use the following key-mapping, things work exactly as I want:
inoremap <C-s> <esc>:w<CR>
However, I would like to avoid pressing CTRL and s at the same time. It is possible there is some problem with the <leader>, but I cannot figure out what it is (I am using , as my leader key).
Though one could discuss the suitability of your insert-mode mapping, the root cause of your problem is a trailing space in the mapping definition; i.e. Vim reads this as follows:
inoremap <leader>w <Esc>:w<cr><Space>
You'll even see this in the :imap <Leader>w output! <Space> in normal mode advances the cursor one to the right (like l); that explains the unexpected move.
Try this instead:
inoremap <silent> <leader>w <C-o>:w<CR>
The idea is Ctrl-o can be used to run commands directly from insert mode. See :help i_CTRL-O for details.
Why not simply doing
inoremap <leader>w <Esc>h:w<cr>
(not the additional h for going back one character)?
How can I remap my CTRL-A to CTRL-Q in the command line mode?
I use VIM within Tmux session (which has CTRL-A set as a prefix). When I try to insert all files which names match the pattern (i.e. for :bd command) I have to press CTRL-A twice (as it's also a prefix for tmux). I would like to use one key stroke <C-a> for that.
I've tried to put cnoremap <C-q> <C-a> to my .vimrc but it doesn't work. Any suggestions?
This works for me; note that in the terminal, Ctrl-S and Ctrl-Q are special sequences for flow control. See here for how to unconfigure that, or use another left-hand side for your mapping, e.g. <C-g>.
Thank you guys for letting me know that is special key, I wasn't aware of that.
In that case I decided to use different key (<C-b>). Key map for that:
cnoremap <C-b> <C-a>
I know that <C-b> is for scrolling but I guess in command line mode it should be ok to use that key.
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
noremap :hsp :botright new
noremap :vsp :botright vnew
"Not an editor command: hsp"
I'm probably googling the wrong thing, but I can't find many results on aliasing vim commands. I can find tons of info about mapping keys to commands like my one for tabs:
noremap <C-t> :tabnew<CR>
But can't find commands mapped to other commands.
What you're doing is simulating a command with a mapping. You're saying that when you press the 4 keys :hsv in normal mode, it should type out the keys :botright new (which would need a <CR> to run, as others have said), but it's not actually making the command hsv. You could make an actual command with a user command (:h user-commands). These must start with a capital letter, though.
:command Hsp botright new
:command Vsp botright vnew
Now you can type :Hsp and hit enter to run the command botright new.
Did you try command abbreviation?
ca hsp botright new
ca vsp botright vnew
You will have to initialize the expansion of the abbreviation by hitting the space key afterwards. Depending on the global vim configuration, expansion also happens automatically just when enter is pressed.
with your same mapping, I cannot get the Not an editor command: hsp error message with my vim (v7.4).
Your mapping works fine, but you don't have <cr> at the end, so when you press :hsp in normal mode, your mapping will switch to commandline mode, and put the mapped command there, without executing it. You have to manually press Enter.
#XZS's answer works, but keep in mind that it is an abbreviation(ab), not a mapping. ab is not command aliases, it is not exactly same as mapping. For example, you have to press another key (like space) after hsp to trigger the ab. also, you cannot ab some special keys, this would be another limitation of ab.
There is c(nore)map for command mapping.
e.g. you could have:
cnoremap hsp botright new
with above line, as same as your original one, you have to manually press Enter, if you want it to be executed, you need add <CR> at the end of the line.
I think if I do this, I would create mapping.
Creating command alias can be tricky:
Using a simple cabbrev and/or cmap will cause expansions and mappings to fire in unexpected places like during searches with / and in the middle of filenames.
cmap's will have a visible delay in outputting to the screen which is why cabbrev is often used.
However there are a few ways to create a proper alias:
Create a command via :command.
e.g. command W w
command's first letter must be a uppercase letter
must supply -nargs, -bar, -complete, and -range options according to the needs of your alias
Expression :cabbrev to guard the abbreviation from expanding in in proper places.
expression mapping use the <expr> option
verify getcmdtype() is equal to :
verify the abbreviation is at the beginning of command line via getcmdline() or getcmdpos()
e.g. cnoreabbrev <expr> W getcmdtype() == ':' && getcmdline() ==# 'W' ? 'w' : 'W'
Use :Alias via the cmdalias.vim plugin by Hari Krishna Dara
e.g. Alias W w
uses an expression cabbrev under the covers similar to the technique above
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