I have a Ubuntu 12.04 OS. I installed vi and vim, but the backspace doesn't work properly. It is doing the same thing that delete key do.
I am expecting the backspace key to delete a character backwards, but it deletes forwards. I did some search on the Internet, there are too much suggestions for changing the .vimrc file, but non of them worked for me.
Is there anybody who has the same issue?
As explained in answer SO/a/10197995/1699311, you have to correct your terminal setting.
However, if you really want to stick with incorrect terminal behaviour (which will affect some other programs) you can instruct Vim to accommodate with that with :fixdel (it internally swap Backspace and Delete keys.)
All the previous suppose you don't have some mapping on that key.
Try adding the following to your .vimrc file, which would correct the behavior of the backspace key:
set backspace=2
Also, you can execute it inside vi/vim command mode:
:set backspace=2
Additionally, here is more information and solutions if this doesn't work for you: http://vim.wikia.com/wiki/Backspace_and_delete_problems
If your backspaces deletes forward you can use the command in vimrc file as shown below
set backspace=2
now on the vi command mode do the follwoing to re-excecute the .vimrc file
:so %
To know which .vimrc file is being read do the following
:echo $MYVIMRC
Related
I'm having a weird issue with vim on Ubuntu. I've been using it for the last few weeks, trying to learn, on Windows and it behaves differently now that I'm using it on Linux.
I noticed that while in insert mode pressing backspace will delete text just like any other editor on Windows, but on Linux the text is "deleted" yet it stays there until I press ESC or write over it.
I was trying to fix this but I'm confused as to whether this is intended behaviour or not. It happens in gvim too.
The reason of this question is this, however:
I deleted my .vimrc file to see if any of my config was at fault and it fixed it. Backspace was now back to its regular self.
But then I tried creating an empty .vimrc file and that made it go back to the delayed delete. It's empty. Why the hell?
So I have no idea what's causing this. Hope my question makes sense my English ain't the best. Thanks.
Alright so looking at :h compatible I found this:
"When a |vimrc| or |gvimrc| file is found while Vim is starting up,
this option is switched off, and all options that have not been
modified will be set to the Vim defaults. Effectively, this means
that when a |vimrc| or |gvimrc| file exists, Vim will use the Vim
defaults, otherwise it will use the Vi defaults. (Note: This doesn't
happen for the system-wide vimrc or gvimrc file, nor for a file given
with the |-u| argument). Also see |compatible-default| and
|posix-compliance|."
So if I'm getting this right, running Vim with a .vimrc file should automatically set nocompatible and running it without one should set compatible... ? Whatever the case, I tried checking with :verbose set compatible? and it always says nocompatible is on so the -N flag shouldn't do anything... Yet it fixes the issue.
Without a vimrc Vim will load /usr/share/vim/vim80/defaults.vim (depending on your vim version). In this file the bs/backspace parameter is set to 2, or actually it is indent,eol,start which is the same as 2 (see :h bs)
Now if you create an empty .vimrc, defaults.vim will not be loaded, so your bs will possibly be 0.
This behaviour is described in :h defaults.vim
So to solve your problem, just put set bs=2 in your .vimrc
Alright I fixed it.
Running vim with the -N command makes it work properly. I'm not sure why but that's what's happening.
I used to use ctrl+left/right to navigate between words (I know I'm supposed to use b/e etc in vim, but...). But starting today, ctrl+left/right deletes the next 4 lines! I tried disabling my plugins one by one, but it didn't help. I also have triple checked my vimrc file -- nothing there.
Where else are vim key mappings defined? Is there any plugin that can cause this behaviour? The only recent change that I have made has been changing my colour scheme to Solarized.
Thanks
Edit: I found the cause. It's a line I have added to .bashrc to have 256 colors. The line is export TERM="screen-256color-bce" . I still don't know how to correct it (aside from removing the line)
:verbose map will show you all mappings and also where they were set from.
If you only want to see maps for specific mode (like normal, input, or visual), use :verbose nmap, :verbose imap, or :verbose vmap.
This also may be not because of Vim, but because of terminal application. Did you change therminal or its settings recently?
The problem was because of a line I have added to .bashrc to have 256 colors in vim. The line is export TERM="screen-256color-bce". I removed that line and instead added set t_Co=256 to .vimrc before setting colorscheme. Now vim uses 256 colors and the key mappings work properly.
I am working with vim on debian.
When I press ctrl-] vim beeps, inserts a new line and goes to "visual block". It does not jump to tag. The same happens with :ctrl-]. Even in insert-mode with ctrl-] vim exits from insert-mode, insert new line and goes to 'visual block'.
But when I use such lines in .vimrc
nnoremap <F3> <c-]>
vnoremap <F3> <c-]>
jumping with F3 works.
Command :verbose map c-] returns No mapping found
update:
As we have discovered in insert mode we can see how vim is interpreting <c-]>. In insert mode after <c-V><c-]> the correct output should be ^] . But my output is
t
^C
Screenshots: after <c-v> I get
And after <c-v><c-]> .
So vim isn't receiving the keystrokes properly. How to check what changes input?
try running vim -u NONE to check if that's happening without any configuration, that way you can be sure it's not a mapping or misconfiguration.
if that solves the issue, check your vim configuration!
Also try doing it in gvim and gvim -u NONE to narrow down the issue to what it's very likely to be. If that works it's a shell or terminal misconfiguration.
if it still fails in the windowed GUI of vim, that means this is X that is wrong, try using xev to see what your key outputs, and xmodmap to printout the values assigned to all your keys on your keyboard layout.
Try using another terminal (like urxvt, gnome-terminal, xterm or the raw linux console), to determine whether it's a terminal emulator misconfiguration of your keys or if it's your shell.
if it's your terminal emulator, then get through the configuration or reset its configuration, there's something setup that shouldn't have been.
Try changing shell to see if that improves (by I doubt it will)… And add the following configuration files in your home directory:
.inputrc
Tab: complete
set meta-flag on
set input-meta on
set output-meta on
set convert-meta off
If that's not enough, you might want to check as well you stty settings for your current shell as well.
If none of that helps, then… take a big hammer and hit very hard your keyboard and your computer, that won't solve your situation, but you'll feel better!
HTH
I have been trying to map ctrl s to save during insert mode in vim. It never seem to work
http://vim.wikia.com/wiki/Map_Ctrl-S_to_save_current_or_new_files (and many other tutorials) does not seem to work
I am using iterm, vim 7, and I have .vimrc file under my current user. I have reloaded my .vimrc with :source $MYVIMRC
Did I do something wrong?
Same thing with mapping any other key. mapping just does not seem to work.
Many keys cannot be intercepted on terminal, because they are interpreted by the terminal and not passed to vim at all. Ctrl-S is one of those keys, meaning "suspend" to most terminals. Either use the GUI version of vim, or select key combinations that work on your terminal.
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.