from cscope i got this nmap:
nmap <C-\>s :cs find s <C-R>=expand("<cword>")<CR><CR>
and i had these maps originally:
nmap <tab> v>
nmap <s-tab> v<
vmap <tab> >gv
vmap <s-tab> <gv
Now if i type s, then it will jump to the definition with one side effect:
it will tab the target line or target function/class content.
I can't find out where is this conflict. It seems that these two maps have no relationship.
I have tried out your mappings w/o any issue, so I assume there might be some kind of trailing charter issue like #glts suggested in his comment. Use :set list to show invisible characters.
However there are somethings you may want to consider:
Unless you are mapping to a plugin or a very special need you should almost always use nnoremap over nmap to prevent recursive mappings.
The vim way to indent/unindent is to use >> / << (or > / < in visual mode). If you want to repeat the command then use .. The dot command will redo the last change. You can use u to undo if you have gone to far. Although I understand the want for mappings such as these, learning and making a habit to use . will help you in your journey to vim nirvana.
Example of nice usage of the . command by showing off quick and dirty substitution.
Search for a common pattern in you file /pat
Change text to something else via c. e.g. cgnfoo<esc>
The gn motion will select the current pattern
repeat with . command.
For more help see:
:h mapping
:h .
:h u
:h >>
Related
When writing mappings in nvim, I'm sometimes using a search/replace, for instance in this mapping to creating headings that are the same length as the current line (for markdown etc):
nnoremap <leader>= 0Vyp0v$:s/./=/g<cr>:nohls<cr>
While this clears the search highlighting with :nohls, it still creates the "flash" of the search/replace.
General solution
I would make use of :help function-search-undo and extract the commands into a :function. This won't clobber the current search pattern, and therefore also doesn't affect search highlighting. To be fully neutral, you just have to remove the used substitution pattern from the search history (via histdel()):
function! MakeHeading()
normal! Vyp
s/./=/g
call histdel('search', -1)
endfunction
nnoremap <leader>= :call MakeHeading()<CR>
Note that I've also simplified the visual selection handling: As V always selects the entire line, you don't need to go to the first column (^), neither is the reselection necessary; we can just let :substitute work on the current (pasted) line.
Alternative implementation
That reminds me that the canonical implementation of this functionality uses the :help v_r command, and this indeed requires a re-selection:
nnoremap <leader>= Vyp0v$r=
As there's no pattern involved here, search highlighting is totally unaffected by it :-)
Based on your own answer, I would propose the following:
nnoremap <leader>= :set nohlsearch<cr>0Vyp0v$:s/./=/g<cr>:let #/=''<cr>:set hlsearch<cr>
This just sets the search register to an empty string. So no highlighting. You could even reset it to the previous search string:
nnoremap <leader>= :let olds=#/<cr>0Vyp0v$:s/./=/g<cr>:let #/=olds<cr>
And BTW: Wouldn't yyp:s/./=/g be easier.
I personally have hlsearch off by default and only switch it on, when I need it. To toggle it I have the following mapping in my vimrc:
" Switch on/off higlighting of search string
noremap <F8> :set invhlsearch hlsearch?<CR>
While researching :h :s and :h s_flags`, and doing more looking around here, part of #Ein's answer stuck out to me:
whenever you run the command :set hlsearch there are two effects: It sets the option AND it makes vim forget if you've ever typed :nohlsearch. In other words, changing 'hlsearch' (either on or off) will force the current "highlight visibility" to logically match.
With a combination of using :set nohls and the e flag (:h s_e), I ended up with:
nnoremap <leader>= :set nohlsearch<cr>0Vyp0v$:s/./=/g<cr>:s/thanks#Ein//e<cr>:set hlsearch<cr>
" Broken out
" Turn off highlighting
:set nohlsearch
" Yank the whole line, duplicate it, and replace `.` with `=`
0Vyp0v$:s/./=/g
" Do a replace with something I'll never find in a document (probably), with `/e` to suppress errors.
:s/thanks#Ein//e
" Finally, reenable highlighting
:set hlsearch
Any more elegant solutions are welcome. I think I'll be refactoring some of this into a function soon at least, to allow for using other characters like - for subheadings.
Maybe this goes against the traditional zen of VI, but I get very overwhelmed when it comes to working with rebinding keys in Vi, in particular what can/cannot be bound. I've had a particular headache since moving to nvim with selecting/copying/pasting using visual mode, as well as no longer having access to Home/End to jump to beginning/end of a line while in insert mode.
I was thinking that a way around this, much like I do with my tmux config, is issue a command to unbind all keys in my vimrc, then rebind them all. That way, there's no confusion to what a binding is, and I can easy change and reference a change anytime. Am I going about this all wrong?
You can't really do this. Vim treats "built-in mappings" different from "user-defined mappings". You can't really "unmap" a built-in mapping.
Technically, it stores built-in mappings in a different C struct than user-defined mappings defined with :map. When you do :unmap, it just removes it from the user-defined struct (incidentally, I gave a brief − but incomplete − overview of how this works last week in How to find out what a key is mapped to? at vi.SE).
The only thing you can do is something like:
" Remap all ascii characters; everything below 33 is a control character
for i in range(33, 127)
" | needs some extra love
if i == 124 | continue | endif
execute 'nnoremap ' . nr2char(i) . ' <Nop>'
execute 'nnoremap <C-' . nr2char(i) . '> <Nop>'
endfor
" The above won't remap stuff like `<F1>`, `<Up>`
nnoremap <Bar> <Nop>
nnoremap <F1> <Nop>
nnoremap <Up> <Nop>
" ... etc ... You can use a loop for this as well...
" Now make our own mappings
nnoremap : :
" ...etc...
And the same for vnoremap, etc. but this won't remap <C-w><C-w>, gJ, etc. so you'll need to add even more exceptions for that (the "second key" for these mappings isn't even in a struct, but is a switch/case!)
However. don't do this. Because now rely on your vimrc that you and only you can understand. Just learn the default mappings. This will mean you can use any Vim installation out-of-the-box, and your mappings won't be somehow "better" than the default mappings.
You can put this line near the top of your vimrc to reset all options to their default value:
set all&
But you can't realistically hope to "unbind" the "default bindings" with a single command because:
they are not "bindings", they are "commands",
there's no such command anyway.
You could remap every default command to <nop> (:help <nop>) but that sounds like a lot of work for very little benefit.
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
I'd like to bind these:
CTRLF one character forward
CTRLB one character backward
CTRLN go to the line below the current one ( not in insert mode )
CTRLP go to the line above the current one ( not in insert mode )
Which functions should I bind? How could I find them?
On vim.org you can find a script called Vimacs : Vim-Improved eMACS: Emacs emulation for Vim
The short description says:
Vimacs (Vim-Improved eMACS) brings Emacs's extensive key bindings and modeless editing features to the Vim world, while completely retaining Vim's powerful moded editing style.
So I guess this is all you need.
If you just want those four mappings and not the full Vimacs, you can do this:
nmap <c-f> l
nmap <c-b> h
nmap <c-n> j
nmap <c-p> k
To get ctrl-f and ctrl-b to work in insert mode add these:
imap <c-f> <right>
imap <c-b> <left>
Check out the map command.
:h :map
You might want to consider learning the vim mappings. (h/l and j/k are shorter than ctrl-f/ctrl-b and ctrl-n/ctrl-p).
Also, check out..
:h index
.. for a list of the mappings.