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.
Related
I have a problem to set my tags file correctly. It use to work without problem after I reinstalled the system. error message like
E433: No tags file
E426: tag not found: Pids
accurs when I press ctrl+].
I have this line in my .gvimrc file
set tags=~/projectdirectory/tags
and tags-exuberant installed properly.
It works fine when I type :set tags=~/projectdirectory/tags in gvim
I also tried use set tags=~/projectdirectory/tags;/
All other .gvimrc settings function well. How this could be possible?
UPDATE:
I have solved the problem, it is because I have multiple tags setting in ~/.gvimrc, vim take the last one in current session.
You can check the actual effective value (after starting GVIM) via
:verbose set tags?
The option might have been overwritten by a later :set command, or a plugin.
Even if you only use GVIM, it's recommended to put the general settings into ~/.vimrc (which is also sourced in GVIM), and keep ~/.gvimrc reserved for GUI-specific settings. An important difference between the two is that the latter is only sourced at the very end, so it's unsuitable for configuring plugins.
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
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
Several users in this epic question put the following in the .vimrc:
" Necesary for lots of cool vim things
set nocompatible
But is it really necessary? From the docs:
'compatible' 'cp'
boolean (default on, off when a |vimrc| or |gvimrc| file is found)
If set nocompatible is going in a .vimrc, that means that a .vimrc file exists, seemingly making it pointless.
If it is the system-wide vimrc, this option won't be off. So, if you're changing the system-wide vimrc and you want it, you need to set it.
From the documentation section *compatible-default* (emphasis mine):
When Vim starts, the 'compatible'
option is on. This will be used when
Vim starts its initializations. But
as soon as a user vimrc file is found,
or a vimrc file in the current
directory, or the "VIMINIT"
environment variable is set, it will
be set to 'nocompatible'.
Another difference is that explicitly setting 'nocompatible' overrules calling vim with the -C flag.
In any other scenario, yes, setting 'nocompatible' in your vimrc is a noop.
In the end I think it's just a matter of "better safe than sorry".
Many people share their .vimrc files on GitHub and I sometimes will test out settings without replacing my .vimrc file. vim allows me to do this with the -u flag.
vim -u test_vimrc
From vim ":help nocompatible"
(Note: This doesn't happen for the system-wide vimrc or gvimrc file,
nor for a file given with the |-u| argument).
This means that if you share your .vimrc with someone and they use -u flag to load your file, vim won't be configured the same as if the file were named .vimrc and located in your home directory.
I was using vim in Cygwin on a Windows VM and every time I was in Insert Mode, pressing arrow keys would result in vim printing "A", "B", "C" or "D" on the screen instead of scrolling. I found a forum that said putting vim in nocompatible mode would fix it. Thankfully, it did.
I put "set nocompatible" in my ~/.vimrc file and the problem remains gone. So perhaps it's not 100% useless.
Based on what Johnny pointed out above, I was simply astonished when I just found THIS out:
$ cat /usr/share/vim/vimrc.tiny
" Debian system-wide default configuration Vim
set runtimepath=~/.vim,/var/lib/vim/addons,/usr/share/vim/vimfiles,/usr/share/vim/vim74,/usr/share/vim/vimfiles/after,/var/lib/vim/addons/after,~/.vim/after
set compatible
ARGH!!!
No I did NOT expect that.
Debian (or Debian Unstable aka Ubuntu) indeed DOES put up a nightmare to their users by overriding the default setting by set compatible.
I hope that you will now know why when you're coming from FreeBSD, the first thing you would have to do is override the system-wide setting by putting a set nocompatible into your own ~/.vimrc. Because otherwise you'd just produce letters instead of being able to move the cursor the way you've been used to.
I think this is a horrid idea. In other words, this set compatible line ought to be removed from the system-wide vimrc.tiny in both Debian and Ubuntu, because it will annoy new users who are not (yet) as smart as knowing how to get the cursor keys working.
It's things like these that force them to nano and others because of such entirely pointless blockers!
I would really want to talk with the dude who once propagated this change to the system-wide resource file in Debian. And maybe also to the people who acknowledged his change to the fullest.
Johnny is right: on your private PC, you may remove said line from the system-wide .vimrc (if there), and touch an empty .vimrc on your $HOME. Thanks so much for pointing that out, way less clutter again. Note that you MUST have that ~/.vimrc (even if empty!) as otherwise you will not be able to use the cursors without explicitly putting in set nocompatible.
got the same problem on using -u vimrc option, even doing set nocompatible was misbehaving with some of my older setting, after some search i found one compactible version that works for me:
" Avoid side-effects when nocompatible has already been set.
if &compatible
set nocompatible
endif
this avoid re-setting of nocompatible flag when it is already set.
vim :help nocompatible shows conditions when it set/resets the options value, scroll to that table of options and values, for quick reference, conditions that effect this behaviour are:
Option is set to the value given in {set value} when 'compatible' is
set.
Option is set to the value given in {set value} when 'compatible' is set AND is set to its Vim default value when 'compatible' is
unset.
Option is NOT changed when setting 'compatible' but IS set to its Vim default when 'compatible' is unset.
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.