The problem is not solved although I accepted one answer.
Problem: Vim updates very slowly the screen in Screen in Mac, although lazyredraw and showcmd are off.
The line numbers get on the foldColumn as below, for instance, when I have line numbers
alt text http://dl.getdropbox.com/u/175564/vimScreenFold.png
When I have nothing in my .vimrc, the problem can be seen by multiplied comment lines on top of one another:
alt text http://dl.getdropbox.com/u/175564/vimScatteredBug.png
I did not type the following comment more than once on the left-hand side
"set list...
Observations
seemed to occur only in comment lines and empty lines. However, I got the evidence (2) which shows that this is not the case.
scatters occurs mostly in the left-hand-side window. They occur also with a single window. However, it is harder to detect with it.
The bug occurs slightly differently when I have nothing in .vimrc. However, the "stagnation" occurs in both situations: with empty .vimrc and with non-empty .vimrc.
Identification of Bug
Dependent variables
dependent on comment signs automatically put by Vim. I noticed disappeared pixels when Vim put Python's comment signs # automatically to my files, when it could not show the whole file.
dependent on at least OS/X Leopard.
Independent variables
file independent: occurs in all files edited by Vim
line independent: occurs in a Python code without comments and empty lines
.vimrc independent: occurs with empty .vimrc
.screenrc independent: occurs with empty .screenrc
shell independent: occurs with Bash and Zsh
Screen version independent: occurs with Leopard's default screen and with Screen 4.0.3
independent of different comment characters: occurs when scrolling down, for instance, .zshrc, .vimrc and .screenrc
How can you disable Vim's default settings?
I'm guessing that the issue might be with your termcap and terminfo settings. Try commenting those out from your screenrc, and restarting screen.
Also, what (non-virtual) terminal are you using?
Ah, it looks like you're using OSX's Terminal.app, which is exactly what I use (with screen/zsh/vim). /usr/bin/screen should work with /usr/bin/vim with an empty .screenrc and .vimrc by default.
% touch empty_screenrc
% cat empty_screerc
% /usr/bin/screen -c empty_screenrc
#...and within screen
% /usr/bin/vim -u NONE
If the problem still persists, the problem may be in your shell. But if this fixes the problem, I'd suggest posting your ~/.vimrc to aid in further diagnosis.
I think that the OS X default version of screen does not support 256 colors. You can set vim to use a lower number of colors in your .vimrc file:
set t_Co=16
On Mac OS X you can rebuild screen to use 256 colors, see here: http://pjkh.com/articles/2008/07/09/osx-iterm-screen-vim-256-colors.
Here's the short version of the instructions:
Rebuild screen making sure to include the 256 colors option:
./configure --enable-colors256
Then you will need to add the following to your ~/.screenrc:
# terminfo and termcap for nice 256 color terminal
# allow bold colors - necessary for some reason
attrcolor b ".I"
# tell screen how to set colors. AB = background, AF=foreground
termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
# erase background with current bg color
defbce "on"
Source
I have no plugins and nothing in in .vimrc and .screenrc.
The problem still persists.
Identification of bug
file independent: occurs in all files edited by Vim
The "stagnation" seems to occurs mostly in comment lines and empty lines.
However, the bug occurs also without comments and empty lines, but the impact of it seems to much smaller.
Picture for the observation 2
alt text http://dl.getdropbox.com/u/175564/cruxMoveInVimScattered.png
I had this problem (just painfully slow) and it ended up being the Consolas font I was using in Terminal.App and ITerm. In my case switching to the Monaco sped things up considerably.
Crux move: the bug seems to occur because some of Vim's default options cause the problem
I use my default configs in .vimrc and .screenrc now, since I observed that they do not cause the bug.
The bug seems to be slighly comment and empty line dependent.
I got an evidence of it.
I have no comments and no empty lines in my Python code. However, I noticed that when Vim cannot show full lines, it puts comment marks to my code. For example, notiche the three # -marks, which Vim put there.
This caused the disappeared pixel.
alt text http://dl.getdropbox.com/u/175564/pythonBug.png
The bug seems to occur in the same file when I cannot see the comment signs automatically put by Vim.
alt text http://dl.getdropbox.com/u/175564/counterExample.png
I duplicated by purpose the code for the picture such that you can see the disappered pixels clearly.
I noticed once when I was playing with the Python code that the "stagnation" occurred greatly after I put a single empty line to the code. However, I have not managed to duplicate the event.
Unsuccessful Attempts to solve the bug by .vimrc
to disable comments signs set automatically by Vim
set formatoptions-=c
It looks like there are some known issues relating to wrap mode for OS X, see number 1. here. It suggests a workaround.
I've had similar problems with irssi and bash, which were caused by colour codes not closed correctly..
Have you tried a different vim theme (specifically the default one), or running :syntax off ?
Debugging:
One suggested me to freeze my terminal from the changes of other applications by
ttyctl -f
However, it did not seem to solve the problem.
Nevertheless, it may help us to find the bug, since we do not have other apps changing the situation now.
Related
When using gVim, whenever I switch between two tabs where one tab is split vertically and the other is not, the horizontal size of the window is decreased by a small amount (probably one column).
This is really annoying as it forces me to resize the window every few minutes.
The behaviour can be reproduced as follows:
start gvim
create new tab :tabnew
split window vertically Ctrl+W v
switch tags gt (--> window size will decrease)
Is this somehow intended behaviour or is it just a bug? Anyway, is there some way to prevent this?
In case it matters: I am using Ubuntu 12.04 with Xfce, using the vim version from the repos (7.3, Included patches: 1-429).
Update 1
I followed the instructions of the FAQ posted by nMontu and tracked the issue down to the following line of my .vimrc:
set guifont=Meslo\ LG\ S\ DZ\ 12
Actually the issue is the font size, if I change it to
set guifont=Meslo\ LG\ S\ DZ\ 10
the problem is gone (leaving me with the problem of a too small font, of course...). It's only the font size, changing the font itself does not solve the problem. For other font sizes != 10 the problem is also there (I tested with sizes 8-14).
Update 2
I updated vim to version 7.4 and when testing with empty buffers, the problem is gone, even when using a font size != 10. However, as soon as I open files, it is there again :(
Following your steps on Linux Mint doesn't show the error. I've executed one hundred tabpage switches and the there was no change on the window size (qmgtq to record a macro, 100#m to execute it).
Notice that vim 7.3 is quite old, you should try updating it to 7.4. But the error you are experiencing probably isn't a vim bug. You should try to follow follow the procedure described on Vim-FAQ 2.5:
2.5. I have a "xyz" (some) problem with Vim. How do I determine it is a
problem with my setup or with Vim? / Have I found a bug in Vim?
First, you need to find out, whether the error is in the actual
runtime files or any plugin that is distributed with Vim or whether it
is a simple side effect of any configuration option from your .vimrc
or .gvimrc. So first, start vim like this:
vim -u NONE -U NONE -N -i NONE
this starts Vim in nocompatible mode (-N), without reading your
viminfo file (-i NONE), without reading any configuration file (-u
NONE for not reading .vimrc file and -U NONE for not reading a .gvimrc
file) or even plugin.
If the error does not occur when starting Vim this way, then the
problem is either related to some plugin of yours or some setting in
one of your local setup files. You need to find out, what triggers the
error, you try starting Vim this way:
vim -u NONE -U NONE -N
If the error occurs, the problem is your .viminfo file. Simply delete
the viminfo file then. If the error does not occur, try:
vim -u ~/.vimrc --noplugin -N -i NONE
This will simply use your .vimrc as configuration file, but not load
any plugins. If the error occurs this time, the error is possibly
caused by some configuration option inside your .vimrc file. Depending
on the length of your vimrc file, it can be quite hard to trace the
origin within that file.
The best way is to add :finish command in the middle of your .vimrc.
Then restart again using the same command line. If the error still
occurs, the bug must be caused because of a setting in the first half
of your .vimrc. If it doesn't happen, the problematic setting must be
in the second half of your .vimrc. So move the :finish command to the
middle of that half, of which you know that triggers the error and
move your way along, until you find the problematic option. If your
.vimrc is 350 lines long, you need at a maximum 9 tries to find the
offending line (in practise, this can often be further reduced, since
often lines depend on each other).
If the problem does not occur, when only loading your .vimrc file, the
error must be caused by a plugin or another runtime file (indent
autoload or syntax script). Check the output of the :scriptnames
command to see what files have been loaded and for each one try to
disable each one by one and see which one triggers the bug. Often
files that are loaded by vim, have a simple configuration variable to
disable them, but you need to check inside each file separately.
Edit
Vim's documentation is extremely well-written and very comprehensive. You are likely to find most of the details about Vim there. It also has a great FAQ, which can be viewed directly on Vim through this nice plugin.
Vim-FAQ 31.2 has a list of useful references:
For more information, read
'guifont'
'guifontset'
'guifontwide'
font-sizes
-font
-boldfont
-italicfont
-menufont
-menufontset
In special, on :help font-sizes:
Note: All fonts (except for the menu and tooltip) must be of the same
size!!! If you don't do this, text will disappear or mess up the
display. Vim does not check the font sizes. It's the size in screen
pixels that must be the same. Note that some fonts that have the same
point size don't have the same pixel size! Additionally, the
positioning of the fonts must be the same (ascent and descent). You
can check this with "xlsfonts -l {fontname}".
I don't know the font you mentioned (Meslo), but I would guess it is not mono-spaced.
Edit 2
Meslo is mono-spaced
It is possible that Meslo won't work, similar to what is stated in its FAQ:
Q: Can I use Meslo with ... ?
A: As for ... I don't know (yet). You may have to try it out. I do
know however that for the time being there appears to be a problem
with an application called SecureCRT which does not recognise Meslo as
a monospaced font. (see also: issue 2)
And issue 2 seems similar to your problem.
I'm trying to use Meslo in a terminal app that requires a fixed-width
font, but when I choose Meslo, it's claiming the font isn't
fixed-width.
You also mentioned that
and besides I am getting the same issue with other mono-spaced fonts
(i.e. 'Monospace') as well.
It is strange that it occurs with common mono-spaced fonts, as this kind of problem would certainly have been reported. If you are sure that it happens with fonts that follow the requirements on the Vim documentation then you should fill a bug report.
I'm very accustomed to typing `. when I open a file to resume editing where I last left off.
On the default Vim 7.3 that came with my new OS X 10.9 Macbook this behavior doesn't work... it says E20: Mark not set. Any idea how to enable this? When I type:
:set viminfo?
I see that viminfo appears to be set to something reasonable:
viminfo='100,<50,s10,h
[UPDATE: Turns out my .viminfo file was owned by root for some reason. Using chmod to change owner back to myself solved the problem.]
I reproduced your problem on my Ubuntu machine. The original output of set viminfo? was just like yours.
viminfo='100,<50,s10,h
After putting the following line in my .vimrc, I was able to jump to the former cursor location using
`.
set viminfo='10,\"100,:20,%,n~/.viminfo
I got that line from this vim tip, where each part is also described.
Update: The OP already solved his problem, which was related to permissions on .viminfo, but I am leaving this answer up in case it helps future people who did not have that particular issue.
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
I enabled syntax highlighting for my C files by issuing the command :syntax on. I expected it to change the colors of keywords etc. But to my surprise, syntax highlighting is happening, but all keywords are being underlined instead of being colored!
Am I missing out something?
It seems that the problem is not with vim as such. The problem is with the terminals I am using. According to VIM Documentation, the terminals I was using, vt100 and xterm don't support colors! And hence no colors in vim too!
But to my surprise, on another server, xterm seemed to support 8 colors. I found this by running /usr/bin/tput colors which outputted -1 on the server where there were no colors and 8 on the server which supported colors.
Thanks to #Idigas for the appropriate pointers!
Probably not. If syntax on is changing the looks of your buffer to something different than what you expect, you might want to check out the contents of your colortheme.
Try :echo g:colors_name to see which one it is, and then editing the aforementioned file.
Also, :hi Normal and let's say, :hi Comment and see how it looks in there.
Try adding
set term=ansi
to your ~/.vimrc file to override your term setting for the duration of your vim session.
I have a problem with a setting in my gvimrc. I like to always have all windows the same size so I specify the following:
set lines=90
set columns=90
This works fine except when I open gvim with the -p argument for multiple tabs. The statusline and ruler are hidden until I manually resize the window. This only happens when the lines/columns are specified AND I use the -p argument. Is there a way to prevent this on startup other than manually dragging the window around to redraw the ruler/statusline?
I'm using gvim 7.3.154 in ubuntu 11.10.
The solution to this is actually spelled out when reading the gvim documentation on 'lines', see :help lines.
from :help lines
"If you get less lines than expected, check the 'guiheadroom' option.
When you set this option and Vim is unable to change the physical
number of lines of the display, the display may be messed up."
I was able to set guiheadroom=100 on my system and avoid this problem completely. The 100 was just a guess on my part. The default value for this is 50, so if you run into this problem you should set it to something > 50. I was able to go as small as 80, but your mileage will most likely vary depending on your OS, window manager, etc.