I tried
inoremap <c-`> <c-w>w
and various combination, but nothing seems to work. Is cntrl-` already mapped?
Using Lubuntu 64 bit 16.04 : lxterminal
Attempted cntrl-v cntrl-` to find the character but nothing shows up.
FYI: I am attempting to make sure I can do same thing with my VSCode editor.
In a typical terminal, control` is an ASCII NUL (zero), which vim will not map. Using cat -v to make the result visible, you'd likely see
^#
which is a single character...
You'd have the same behavior for a few other keys which typically produce a NUL, e.g., controlspace, or control# (really!)
You can't map anything to Ctrl-Backtick because Vim won't recognize it no matter what you do.
Find another key combination.
As #romainl and #Thomas Dickey pointed out, you can't do this in terminal vim.
If you want this is in VSCode, just add this to keybindings.json and add this to the editable pane.
// Place your key bindings in this file to overwrite the defaults
[
{ "key": "ctrl+`", "command": "workbench.action.navigateEditorGroups" },
]
This will work as VSCode doesn't have the same problem of interpreting ctrl` as your terminal.
Also, it might not be a good idea to use ctrl` as it is already being used for toggling integrated terminal
⌃` Toggle Integrated Terminal workbench.action.terminal.toggleTerminal
How to modify keybinding for VSCode
Is cntrl-` already mapped?
No. Even if a key combination is mapped, you can override it in vim.
Attempted cntrl-v cntrl-` to find the character but nothing shows up.
Now you know why
Well, as two other answers indicated. I could NOT find the key combo & I do NOT think I will; however, when using nyaoVim the key combos do work. So, it's just terminal issue.
A bit of pain to install but now everything pretty much works!
Related
I have this problem in emacs when using it in console: when pressing C- it just inserts a space instead of invoking the set-mark function as it should. The control key works in console, as other key combination including CTRL key work (e.g C-h-b, C-x C-c).
Under X every keybinding works correctly, so I suppose it is not an emacs problem, but rather a console related one. Does anybody have an idea at least where to start to look for a solution?
edit: thanks for the links but it doesn't work either
after hitting C-h l (shows the keys input to emacs) I noticed that emacs doesn't get C-space at all, just space. But emacs still gets the other Ctrl keys combinations correctly. I am using the linux console, and as far as I know (correct me if I'm wrong) it's not an emulator: it is the terminal. Unfortunately I have no idea how to fix this annoying bug, as I find emacs very useful.
But you can also mess around with the keymaps in /usr/share/kbd/keymaps (load a new one with loadkeys) and see if you can figure out what's happening.
Thanks deong :), that solved my problem: I loaded another compatible keymap with `loadkeys other-keymap'.
I didn't think about it because CTRL worked everywhere else. So am I to understand that in the previous non-working keymap "Ctrl-space" was mapped to "space"?
I am using Cygwin 1.7.22 (32-bit) on Windows 8 (64-bit). Within Cygwin, I am using Vim 7.3.1152, which is the default version.
Behavior that seem like bugs:
When I press I to enter insert mode, it does not say -- INSERT -- in the bottom left. In fact, it doesn't say anything. It does behave correctly, though.
When I delete letters using Backspace in insert mode, the letters do not disappear but the cursor does move to the left.
When I use the arrow keys in insert mode, it enters the letters A, B, C, and D, rather than moving the cursor. The arrow keys work normally outside of insert mode.
How do I make Vim behave as I expect?
Create a ~/.vimrc file with the following contents to put vim in nocompatible mode (actually the mere presence of the file is sufficient.)
set nocompatible
The behavior you are seeing is how vi used to behave. These are not bugs.
Take a look at :h nocompatible
In vim compatible mode tries to emulate vi as closely as possible.
--insert-- is not part of vi so it not shown in compatible mode.
I believe vi did a lazy redraw of the screen and didn't update until you exited back to normal mode. Also backspace is only usable also only works on stuff that was entered in the current insert mode. Overall its not very user friendly.
The arrow keys are sent to vim as escape sequences (escape followed by a coupled of letters). Let ^[ be escape. ^[OA is up on my computer its probably something similar on yours. vim sees this as an escape (goes back to normal mode), and O (add a line above the current) and A which is the A you see entered onto your screen. This just means that vim in compatible mode does not interpret the escape characters properly. Most likely because vi did not interpret them (nor was it designed to use them).
set nocompatible fixes problems 1 and 3.
I think set backspace=indent,eol,start should fix problem 2.
This was asked months ago, but I am answering for future reference for anyone else who encounters this problem.
I was just bitten by this issue. All advice listed in this post, and in other posts on this forum (not to mention posts on other forums) does not work, at least for some of us. I finally figured out the real issue.
vim on cygwin, for whatever reason (at least this was the case for me) does not use the .vimrc you put in your directory. Let's say you copy the example one to your working directory, or copy some .vimrc from online. Or maybe you create a new one from scratch, and put all the settings the good people here and elsewhere recommend (set backspace = blahblah, set nocompatible, set this, set that). It doesn't work. Why? Because for whatever reason (at least in my case) vim isn't looking at the .vimrc you just created.
The solution is to FORCE vim to use a particular .vimrc, by passing in -u on the command line like so:
vim -u [/INSERT/PATH/TO/.vimrc]
For the love of all that is holy, DO NOT type square brackets or the words "/INSERT/PATH/TO/.vimrc" verbatim. Use your brain please.
Anyway, this solved my problems and I was able to use the default example .vimrc and get proper delete and backspace behavior while in insert mode, not to mention other goodies.
You might want to alias the vim command in your .bashrc like this:
alias vim='vim -u [/INSERT/PATH/TO/.vimrc]'
Regarding A,B,C,D for arrow keys in Vim, adding:
:set term=cons25
to ~/.vimrc worked like a charm.
source: http://vim.wikia.com/wiki/Fix_arrow_keys_that_display_A_B_C_D_on_remote_shell
Following different answers in this topic I found a simple solution.
$ vi --version | head
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Mar 30 2020 21:54:08)
Included patches: 1-486
Modified by <cygwin#cygwin.com>
Compiled by <cygwin#cygwin.com>
$ vi --version | grep 'user vimrc'
user vimrc file: "$HOME/.virc"
2nd user vimrc file: "~/.vim/vimrc"
So I just created ~/.virc (not vimrc) and it works! The content of the file:
set nocompatible
Probably, if you already have this file you will add the above string in it. Or, as people say above, if you have an empty ~/.virc, nocompatible mode must be already in use (I didn't check it).
Apart of the question, line numbers (that I find very useful) may be shown in vi by adding:
set number
Okay, so I've been trying out Vim (the standard console version; my OS is Linux Mint 13) and I'd like to get rid of having to use the Escape key to change modes. Preferably, I'd like to swap the Capslock and Escape keys, but as far as I've heard, that's not possible within Vim itself. Most "solutions" I've found involve changing the key on a global level (using xmodmap or whatever), but I don't really want that. If there's an easy way to swap Capslock and Escape only in Vim, please let me know.
Another common thing I've heard of is using "Ctrl-[" as an equivalent to Escape. However, because I'm using a German keyboard with a different layout, that's not an option. So, I thought I'd use noremap <C-ü> <Esc> in Vim (the "ü" key on a German keyboard is in the same place as the "[" key on US keyboards), but that didn't work, either. I'm assuming that's because "ü" isn't an ASCII character. Is there any way to get either of these options working?
UPDATE: Well, this is strange. After experimenting some more, it seems that "Ctrl-ü" does work after all. I'm not sure what happened – maybe I messed up some encoding-related settings while trying different things? If there is no good solution for remapping capslock, I guess I will stick with "Ctrl-ü".
So, yeah, eventually I decided to go with <C-ü> because it doesn't conflict with anything else and because it's the same as <C-[> on US keyboards.
However, because I'm getting tired of using the German keyboard layout for programming (for example, to get "{" you need to type "Alt Gr-7"), I'm switching my keyboard to US-International, which essentially has a similar effect as far as Vim is concerned. It also helps if you want to want to get into the habit of touch-typing; you actually can't look at the keyboard because the keys aren't labeled "correctly" ;-)
A lot of people use jk:
inoremap jk <Esc>
You can also simply do <C-c>.
Here is another alternative that may be useful to you! It involves changing the keyboard file related to VIM. I found this suggestion on this youtube video
$ cd /usr/share/X11/xkb/symbols/
sudo vim pc
to edit the capslock key to escape, change the capslock line to read as follows:
key <CAPS> { [ Escape ] };
:wq # to write and close the file
Log out and log back into the machine and it should be updated!
I noticed that iTerm2 offers the very convenient feature of using "Option key as +ESC" (or as meta, but apparently that's obsolete).
I tried them both and the option key works as expected in Bash (set -o emacs mode) and Emacs, but not in Vim. Thus, I can't make use of any "M-" bindings.
What I've found is that:
if I set option to "+ESC", vim just understands ESC+key, and has no idea I actually meant Meta-key.
if I set option to "meta", keys modified with "option" behave just as without a modifier (don't know how to formally test what vim understands from a key combination that I'm typing).
"M-" mappings work perfectly in MacVim (7.3.53), but that's outside of a console and not in the scope of this question.
I'm interested in how to make those mappings work in Vim, under iTerm2 or Terminal.
My specs:
MAC OS X Lion 10.7.2
iTerm2 1.0.0.20111020
vim #7.3.107_0+python26 [though MacPorts]
I've downloaded the latest iTerm2 and tried to see what it sent to/what was printed by Vim (i<C-v><M-a>) with the following settings:
Option as Option:
Vim prints æ which is normal and expected on my french keyboard
Option as Meta:
Vim stays there, waiting for something to happen. Nothing is printed. If I press Option and a in sequence I just obtain a. Pressing Option and a in some random order may print á, which is weird and totally unexpected.
Option as +ESC:
Vim prints ^[a which means "Escape character followed by the character a".
From these tests it appears that Vim will never ever receive <M-> without some hypothetical black magic.
If you stick with "Option as +ESC", it seems that you will have to change all your custom <M-something> mappings to <Esc>something. This may work but it will make writing any kind of prose in any non-english language a pain.
What I do: I leave the Option key as it is so that I can type characters like œ…«» easily and I use <Leader> (mapped to ,, see :help mapleader) for all my custom mappings.
Some people here like to reserve it for plugins and advocate a somewhat simpler and potentially safer approach.
inoremap <leader>, <C-x><C-o> "my way (copied elsewhere)
inoremap ,, <C-x><C-o> "another way
I left my option key to act as Normal and discovered that Vim saw them as <T- bindings. So, for example, I have this mapping setup in my .vimrc to move to the end of a word when in Insert mode:
noremap! <T-Right> <C-o><Right>;
I'm trying to get into Vim. I'm running it in the terminal on OS X.
Anytime I hit the delete key, it simply changes case of that letter instead of deleting it. When I SSH into my server and use Vim there, it deletes normally.
Any ideas what may be going wrong?
The problem
The Del key generates the code ^[[3~ in my urxvt terminal on GNU/Linux, and might generate a similar code in your OS X terminal.
My theory is that Vim for some reason doesn't recognize any keybinding for the delete key, and simply tries to interpret the string ^[[3~ as input instead. ^[ is the keycode for the Esc key (which puts you in normal mode), and ~ is the Vim command for changing the case of a letter (from normal mode).
You can confirm the keycodes I mentioned by pressing Ctrl+V Esc and Ctrl+V Del from insert mode in Vim. Ctrl+V means that the next character should be inserted as text instead of being interpreted by the editor.
The solution
As for the solution, try editing your Vim configuration file (presumably ~/.vimrc):
vim ~/.vimrc
And append the following code to it:
nmap <Ctrl-V><Del> x
imap <Ctrl-V><Del> <Ctrl-V><Esc>lxi
I hope this helps :)
The problem was that in my .vimrc I had
set term = ansi
Took that out and all was well - sorry about the troubles, thanks!
Well, this took forever for me to resolve. When using vim I was in Iterm2 on macOSx to access a Centos5 system via gnu screen. Not only was the delete key changing the letter case, and causing delays in vim, but also the arrow keys didnt work. I think the problem was simply in the old configuration on the Centos5 machine, but may have had something to also do with either iterm or gnu screen, but i hadnt had this issue at all on any Centos6 systems.
What did Not work:
I compile vim 7.4, that did not resolve it, so don't go down that path.
I also tried these configurations that did not work
"set term=ansi
"set backspace=indent,eol,start
"set nocompatible
"fixdel
":if &term == "xterm"
":if &term == "xterm-256"
": set t_kD=^V<Delete>
":endif
"nmap <Ctrl-V><Del> x
"imap <Ctrl-V><Del> <Ctrl-V><Esc>xi
I finally found the solution.
Solution: Set the following in .vimrc
set term-builtin_xterm
Additionally, you may also notice that 256 colors have an issue on this same system. So if it helps, you can check your TERM environment variable echo $TERM. If it is xterm you can switch it to 256 colors, e.g. export TERM='xterm-256color to get the color schemes back on track for this same system. reference
I had the same issue where vim suddenly interpreted keys differently.
The answer for me was that the environment variable $TERM had somehow been to to 'dumb' in my terminal.
I added
export TERM=xterm-color
to ~/.bashrc (in my case) and that fixed all the issues with keys; DEL worked as expected etc.
I didn't need to add or change anything in ~/.vimrc
I should mention this affected more than just vim for me - if you also see 'less' behave differently for example, you may have the same cause as I did.
I use vim regularly on my OSX machine (vim version 7.2.108), and I do not have this issue. Try renaming your vimrc file and then reload vim, and see if the issue persists. If there is no issue after renaming you vimrc file, then your issue is in that file.
On my machine, my vimrc file is pretty much empty:
set ruler
set tabstop=2
set cindent
set number
syntax on
None of these solutions worked for me, until I found a solution on the vim fandom website.
Those solutions are for a similar problems with arrow keys, which I was experiencing in addition to the delete key problem.
Solution 8 fixed it for me, the problem was that I had remapped <Esc> to <Esc>l in order to move the cursor right every time I entered normal mode, evidently this caused any other key code with included ^[ (which is the escape code) including the arrow keys ( ^[OA ^[OB etc ) and the delete key ( ^[[3~ ) to be misunderstood.
Removing the offending line from my .vimrc fixed the problem.