I have configured vim to use the control+arrow to switch tabs by adding following lines in .vimrc:
map <F7> :tabp<cr>
map <F8> :tabn<cr>
map <C-up> :tabr<cr>
map <C-down> :tabl<cr>
map <C-left> :tabp<cr>
map <C-right> :tabn<cr>
In screen, the <F7> and <F8> works, but the control+arrows do not...
Any idea why? And how to fix? Thanks.
I'm not sure it will work, but you could try to include this code inside your vimrc:
if &term =~ '^screen'
sil! exe "set <xUp>=\e[1;*A"
sil! exe "set <xDown>=\e[1;*B"
sil! exe "set <xRight>=\e[1;*C"
sil! exe "set <xLeft>=\e[1;*D"
endif
I copied it from here.
If you use tmux, you may also need to enable the option xterm-keys inside your tmux config file (~/.tmux.conf):
set-option -gw xterm-keys on
It's described in man tmux:
xterm-keys [on | off]
If this option is set, tmux will generate xterm(1) -style function key sequences; these have a
number included to indicate modifiers such as Shift, Alt or Ctrl. The default is off.
I don't know what the equivalent for screen is.
It's also possible that something (window manager, terminal multiplexer, terminal emulator) is intercepting <C-left> before Vim.
To rule out this possibility, you could try to insert <C-left> literally in a Vim buffer by typing C-v C-left, in insert mode, and see what it displays. On my machine, it displays ^[[1;5D, so I know that nothing intercepts <C-left>.
If nothing is displayed, then you will have to find which software is intercepting <C-left> and remove the key binding in its configuration.
Related
I'm using GVim 8.1 on Windows 10 with no external plugins.
I have the following set up in my .gvimrc file:
let g:build_file_abs_path = fnamemodify(findfile("windows-build.bat", ";."), ":p:h")
" This build script is a basic wrapper for 'clang.exe file.c -o file.exe' style invocation
let &makeprg=g:build_file_abs_path . "\\windows-build.bat"
nnoremap <silent> <C-B> :cd <C-R>=g:build_file_abs_path<CR> <bar> make! <bar> copen <bar> redraw <bar> cd -<CR>
Now, this automatically opens a quickfix window with the correct compiler output. However, when I press ENTER over the error, the cursor jumps to the buffer for the affected file, yet it is completely blank with a single line. Furthermore, this occurs as I use :cn and :cp commands inside the quickfix window. e.g:
Images showing these two states:
before
after
Please note that:
:verbose nmap <CR> returns no mappings, so there is not conflict there.
I would appreciate it if someone could provide some insight as to how to avoid the buffer becoming empty and actually jump to the error in the appropriate file. Many thanks.
Thanks to Christian Brabandt's comment, I was able to solve the issue. I was misunderstanding the distinction between the working directories of vim and the build script. I made the following changes:
let &makeprg="cd " . g:build_file_abs_path . " && windows-build.bat"
nnoremap <silent> <C-B> :make! <bar> copen <bar> redraw <CR>
I am looking for a way to automatically resize my open v-split panes in Vim after I call NERDTreeToggle.
I have NERDTreeToggle being called on the shortcut "ctrl+\" at the moment, and ideally what I want is to call the keyboard shortcut "ctrl+w =" immediately afterwards.
Any ideas? Thanks.
If this is your current mapping:
:nnoremap <C-\> :NERDTreeToggle<CR>
You can just append the window command after it:
:nnoremap <C-\> :NERDTreeToggle<CR><C-w>=
Alternatively, you can execute this from command-line mode as well, via :normal!:
:nnoremap <C-\> :NERDTreeToggle<Bar>execute "normal! \<lt>C-w>="<CR>
Note that for window commands, there's also a special :wincmd to invoke them:
:nnoremap <C-\> :NERDTreeToggle<Bar>wincmd =<CR>
My current .vimrc file is
syntax on
colorscheme zellner
set nu
set ruler
set si "Smart indet
map <C-s> :w<cr>
I thought the last line would allow me to hit control-s to automatically save while in normal mode?
{
The last line is just the trim downed version of what I really want which is
map <C-s> <esc>:w<cr>a
}
Am I forgetting something?
I'm using vim 7.3 that came with my mac.
Like mentioned if you want it on both modes you have to just put
inoremap <C-s> <esc>:w<cr>a
nnoremap <C-s> :w<cr>a
in your .vimrc.
But note that if you are using the terminal vim then you might have a problem
mapping ctrl-s. By default it stops the flow. In that case add the following to your .bashrc (not sure if the same problem in zsh):
stty -ixon
If I got it right, you want
:inoremap <C-s> <esc>:w<cr>a
Whoops, just read you want it in normal mode
:nnoremap <C-s> :w<cr>
When you're writing commands in vim files (like .vimrc) you don't need the :. It is only a method of entering commands on the command line.
I input :map! <C-q> :q <CR> in command line mode, then return to normal mode, and press ctrl-q, but vim does not quit. Why?
As Johnsyweb suggested, Ctrl-Q does not reach Vim in the first place. This holds for the popular Ctrl-S as well. Both can be fixed by adding
silent !stty -ixon > /dev/null 2>/dev/null
to your .vimrc as it forces these control sequences to reach the application.
Why anyone would want to add yet another way of quitting Vim to the plethora already available is beyond me. However...
On Fedora 15, Ctrl-Q is likely being captured by your terminal as XON (resume) and therefore not reaching Vim to quit the application.
You can check if there's an error in your mapping or a clash like so:
:verbose map! <C-Q>
:map! is for specifing mappings in insert and command-line modes.
normal-mode mappings are (usually) specified like so:
:nmap <C-Q> :q<CR>
While CtrlX works fine in vim under windows, CtrlA selects all (duh).
Is there a way to increment a number with a keystroke under windows?
You can make CtrlA to increment in windows by opening up the 'mswin.vim' file in your vim directory and finding the section that looks like:
" CTRL-A is Select all
noremap <C-A> gggH<C-O>G
inoremap <C-A> <C-O>gg<C-O>gH<C-O>G
cnoremap <C-A> <C-C>gggH<C-O>G
onoremap <C-A> <C-C>gggH<C-O>G
snoremap <C-A> <C-C>gggH<C-O>G
xnoremap <C-A> <C-C>ggVG
Comment out all of these lines as follows:
" CTRL-A is Select all
"noremap <C-A> gggH<C-O>G
"inoremap <C-A> <C-O>gg<C-O>gH<C-O>G
"cnoremap <C-A> <C-C>gggH<C-O>G
"onoremap <C-A> <C-C>gggH<C-O>G
"snoremap <C-A> <C-C>gggH<C-O>G
"xnoremap <C-A> <C-C>ggVG
and the CtrlA keystroke will increment.
This is a pretty nice option when your keyboard doesn't have a real number pad.
Try Ctrl-NumPad + ?
(from here)
I realize that this is an old question, but I ran across another option today based on the following question. Making gvim act like it does on linux will allow CTRL-A to work as you expect it to:
how to make gvim on windows behave exacly like linux console vim?
There is a section of the _vimrc that has the following items. These cause many of the control characters to act like they do on Windows.
set nocompatible
source $VIMRUNTIME/vimrc_example.vim
source $VIMRUNTIME/mswin.vim
behave mswin
I commented out (with ") the mswin lines and the set nocompatible line. From there, I added set compatible. This causes gvim to act like it does on linux. Thus, mine looks something like:
set compatible
source $VIMRUNTIME/vimrc_example.vim
"set nocompatible
"source $VIMRUNTIME/mswin.vim
"behave mswin
I just learned this trick today, so if I'm not completely correct in my information, please let me know.
I modified TMealy's solution so that CtrlA still selects all (I find this useful), while CtrlI increments (also useful).
noremap <C-I> <C-A>
" CTRL-A is Select all
noremap <C-A> gggH<C-O>G
inoremap <C-A> <C-O>gg<C-O>gH<C-O>G
cnoremap <C-A> <C-C>gggH<C-O>G
onoremap <C-A> <C-C>gggH<C-O>G
snoremap <C-A> <C-C>gggH<C-O>G
xnoremap <C-A> <C-C>ggVG
A similar problem occurs under GNU/Linux when using Vim with mswin.vim.
Remapping Alt+X to Ctrl+A prior to evoking mswin.vim solved my issue.
execute "set <A-x>=\ex"
noremap <A-x> <C-A>
source $VIMRUNTIME/mswin.vim
behave mswin
Now, Alt+X and Ctrl+X respectively increase and decrease numbers in Vim.
Mapping to Alt key combinations is often not evident in Vim; read more about this here.
I am using cygwin terminal + screen, so <c-a> is captured by the terminal multiplexer. I used this mapping:
:noremap <c-i> <c-a>
It seems that the CtrlA got mapped somewhere in startup.
As suggested before, use:
unmap <c-x>
I would use unmap, not nunmap.