Mapping <C-j> to something in Vim - vim

I have mapped Ctrl-j to move to the buffer below. However it was hard mapped
to something else so I had to write the first row below to make it mappable at
all.
The script below works perfectly, except when I write .sh files. I have
bash-support plugin installed.
let g:C_Ctrl_j = 'off'
map <C-j> <C-w>j
EDIT: I have just found out that the problem is in bash-support. Bash-support
maps Ctrl-j to jump insert (or something like that) which moves cursor at a
predefined point and goes to insert mode. I guess changing that in bash-support
script will do the job though I don't like messing with those files.
EDIT2: let g:C_Ctrl_j = 'off' actually turns the csupport plugin jump insert feature.

According to the document of bash-support.vim:
The original meaning of Ctrl-j is 'move [n] lines downward' (see |CTRL-j|).
If you are accustomed to use the default and don't like these jump targets you
can switch them off. Put the following line in the file '.vimrc' :
let g:BASH_Ctrl_j = 'off'
So that you have to put let g:BASH_Ctrl_j = 'off' into your vimrc.
Additionally, use nnoremap <C-j> <C-w>j instead of map <C-j> <C-w>j in your vimrc.
The latter defines key mappings in Normal, Visual and Operator-pending modes.
The key mappings are also recursively expanded.
It might cause troubles when you define more key mappings.

Ctrl-j (0x0A) is a special character, Line Feed.
There's a good chance that this key-press is not is not arriving at Vim as Ctrl-j (0x0A).
In Vim in a Terminal.app window on my Mac, typing Ctrl-v Ctrl-j displays ^#, (0x00 or NULL). Whereas Ctrl-v Ctrl-g and Ctrl-v Ctrl-k display ^G and ^K, respectively.
I'd suggest using another mapping (or just training yourself to use Ctrl-w j).

I had the same issue, but for a different reason. VIM-LaTeX uses imaps.vim plugin, which also remaps some keys, including Ctrl-j. What worked for me is to set an autocmd in my .vimrc:
augroup vimrc
au!
au VimEnter * unmap <C-j>
au VimEnter * noremap <C-j> <C-w>j
augroup END
The VimEnter trigger makes sure that the remap will executed after vim starts up, and the plug-ins are loaded (if I understand it correctly), so it overwrites the imaps.vim plug-in's maps. The unmap isn't necessary, but it can't hurt.

Try non recursive mappings,
nnoremap <C-j> <C-w>j
ought to do it.

Related

Navigate in gvim like in most

I'd like to use gvim to view files with long lines. It's a table, so I'm not wrapping the lines.
Is this possible to configure gvim so arrows navigation will be like in "most" tool? Arrow key will move the whole screen 1 character lef/right/top/bottom?
Thanks a lot.
I think this should do what you want.
set nocompatible
set nowrap
set virtualedit=all
nnoremap <Left> zh
nnoremap <Right> zl
nnoremap <Up> <C-y>
nnoremap <Down> <C-e>
If you want the same behavior in insert mode, add the same mappings again as a second set, but use inoremap instead of nnoremap.
The virtualedit setting will allow the cursor to move beyond the end of the line and continue on as if the line had infinite whitespace to the right.
NOTE: virtualedit is only available if Vim was compiled with that feature. You can check with :version. If this feature is available, you should see a + next to it, e.g. +virtualedit.

Tab Navigation mapping is not working

NOTE: I am using Terminator instead of terminal. But as all other mappings are working fine why does these are not working.
I have tried to use these mappings in my vimrc file to be able to use Tab Navigation. But its not working at all.
nnoremap <C-S-tab> :tabprevious<CR>
"nnoremap <C-tab> :tabnext<CR>
nnoremap <C-tab> :tabn<CR> "I also tried this
nnoremap <C-t> :tabnew<CR>
inoremap <C-S-tab> <Esc>:tabprevious<CR>i
inoremap <C-tab> <Esc>:tabnext<CR>i
inoremap <C-t> <Esc>:tabnew<CR>
inoremap <C-S-w> <Esc>:tabclose<CR>
"Also to go to the nth tabpage Use <A-Fn>
nnoremap <A-F1> 1gt
nnoremap <A-F2> 2gt
nnoremap <A-F3> 3gt
nnoremap <A-F4> 4gt
nnoremap <A-F5> 5gt
nnoremap <A-F6> 6gt
nnoremap <A-F7> 7gt
nnoremap <A-F8> 8gt
nnoremap <A-F9> 9gt
nnoremap <A-F10> 10gt
NOTE: I have ctags and cscope installed. So I think there might be some confliction as ctrl-t is to jump back from a certain tag. And only this mapping is working for new tab.
Also I have checked ctrl-PageDown is working fine for the same purpose.
2nd Question:
How does this key notation works in vimrc.
Is it something like this:
All modifier keys should be used in Caps like
C for Ctrl.
A for Alt.
S for Shift.
And other keys are all in small.
But what about keys like:
Home
End
Backspace
Escape
PageUp
PageDown
Tab
Function keys etc.
How to use them?
Here
I read that how these should be used in mapping but even they have used tab instead of Tab in mappings.
Brace yourself for disappointment.
The terminal keycodes
Vim accepts terminal keycodes, so not all key combinations are possible. The best way to figure out which keys are recognizable is to open insert mode and press ctrl+v followed by your key combination. This will show you the raw codes. Do this for another key combination. If the raw codes are the same then Vim can not distinguish between them. e.g. ctrl+v ctrl+shift+tab.
Your mappings
You should probably avoid doing insert mode mappings to switch tabs. It simply isn't the Vim Way as insert mode should only be used in short bursts.
Your :tabprev and :tabnext mappings can simplified into gT and gt mappings. Personally I do not mind the default gt or gT mappings.
<key> notation
As far as I know the case does not matter. All my mappings are lowercase. For a list of <> notation please see :h key-notation.
You are correct on the <c-..> for control, <a-...> for alt, and <s-...> for shift. Example combination would be <c-s-space>. Note: most <c-s-...> mappings are going to fail.
Using Tabs
Vim's tabs are not like most text editors tab. They are more like viewports into a group of windows/splits. Additionally, Vim is buffer centric, not tab centric like most editors. For example using features like Vim's quickfix list is often easier without tabs (See :h 'switchbuf if you must use tabs). Vim's tabs often get in the way of using a splits as there are better window and buffer navigation commands available. I personally have many files open (sometimes 100+) using no tabs and use on average 1-2 splits without any issue.
Bottom line: Learn to use buffers effectively.
Conclusion
I would suggest you break this tab workflow quickly and learn to love buffers. You won't really need your mappings and you will not be working against Vim's nature.
Read :help key-notation for an explanation of… Vim's key notation.
It is generally a good idea to play it safe so I recommend to follow these conventions when mapping combos:
always use an uppercase letter for the modifier key, C for Control, S for Shift, A for Alt, D for Command (MacVim GUI only), M for Meta,
always use a lowercase letter for the alphabetical keys, abc…xyz,
always capitalize the first letter of "special" keys, Tab, Space, Up, etc.
Examples:
<S-Up>
<C-r>
<A-LeftMouse>
However, the following notation works just as well so… whatever notation you choose, try to be consistent:
<s-UP>
Using multiple modifiers in a single mapping doesn't work reliably so you will be better in the long run if you completely avoid them.
nnoremap <C-S-j> :echo "csj"<CR>
nnoremap <C-j> :echo "cj"<CR>
now press <C-j> and <C-S-j> in normal mode.
<C-S-w> is indistinguishable from <C-w>.
:verbose map <C-t>
shows you what is mapped to <C-t> and where the mapping occurred. You can use it to debug your mappings.
And I agree with Peter, you are using both tab pages and insert mode wrongly.

Setting mouse=a and mapping <esc> to :noh breaks mouse working on vim? [duplicate]

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

Mapping <esc> in vimrc causes bizarre arrow behaviour

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

Custom keys with NERDComment plugin and remapped Leader?

I'm trying to set up the NERDComment plugin in vim, but I'm having some trouble with the keys. I'd like to set the basic toggle functionality (comment a line if it's uncommented, uncomment if it's commented) to be c. The problem is that I've remapped the Leader to be ,, which is the same key that NERD wants for all of it's hotkeys. Anyone have any idea as to how to set this up?
Just call NERDComment function in your mapping. For example, my mapping to comment the current line:
inoremap ,c <C-o>:call NERDComment(0,"toggle")<C-m>
Here's a breakdown of how this vim remap works.
The i in inoremap means that the remap only applies in insert mode.
The noremap means that the remap can't be overridden later in your .vimrc file by accident, or by a plugin.
The ,c is the key combination that triggers the key map.
The <C-o> temporarily takes you out of insert mode for one command, so the next section of the remap can call the NERDComment function.
The :call NERDComment(0,"toggle") is the NERDComment function being called.
Then <C-m> is another way of saying carriage return, which executes the command.
If you want the comment shortcut to work in normal mode and visual mode, but not in insert mode where it might do something weird when you try to type a comma, you can use the following remaps:
nnoremap ,c :call NERDComment(0,"toggle")<CR>
vnoremap ,c :call NERDComment(0,"toggle")<CR>
documented method of remapping key is located here:
remapping documentation
reference
map <leader>d <Plug>NERDCommenterToggle
"silently rejects remap will not work
nnoremap <leader>d <Plug>NERDCommenterToggle
I fell into the pitfall of attempting to use "nnoremap" to remap on my first attempt resulting in unresponsive mapping. You must use "map", "nmap", etc to properly remap the function
:map <C-z> <plug>NERDCommenterToggle
Maps 'toggle comments' to ctrl+z

Resources