Vim & NeoVim both leave patches of simply black text scattered in random locations across the viewport. This is most common when scrolling or jumping between locations. This affect has happened on multiple different colorschemes so I suspect its more a problem with vim or my shell, than with the scheme. Generally when I load a file these patches don't exist, but they appear pretty quickly after starting vim. Reloading my configuration file or changing the scheme definitely makes them appear. Restarting the shell or quitting and restarting vim doesn't have any affect.
I'm running windows build 17763.92 on windows 10 Education & vim/neovim on Ubuntu (version 18.04 Bionic) bash for windows under the WSL.
Could anyone enlighten me as to why this is happening?
Heres my vim version info.
Heres my vimrc File & A Screenshot of The Described Affect.
This is usually caused by a wrong terminal setting in $TERM. The commands that Vim sends to the terminal to clear it then don't properly set the background color, and only text written on top has the correct background.
If you don't find a fix for that, you can work around the problem by clearing the background color of the Normal highlight group:
:hi Normal ctermbg=NONE
This happened to me as well, I would get black highlighting when opening a new line using o or O, and it would also appear when paging down (ctrl D) then scrolling up (k).
I was using vim (.vimrc - colorscheme desert with syntax on) on windows ubuntu subsystem WSL.
I was able to make it go away by updating my Windows 10 version 1909, to Windows 10 version 2004.
My problem was similar to this post: https://vi.stackexchange.com/questions/21437/vim-is-highlights-everything-after-eol-in-yellow-upon-scrolling
and, someone had also mentioned it being related to the terminal type xterm-256color here (their recommendation was to upgrade Windows version, it worked for me): https://superuser.com/questions/1526515/vim-highlighting-newlines-in-a-file-how-to-disable
Related
That's how it looks like when I start gvim:
When I start typing, black versions of these symbols appear. It looks like gvim simply replaces every character with these strange symbols.
Vim works fine though.
I'm using gvim 7.4 on arch linux.
The problem might have started to occur after I tried to use gvim as my external editor for sylpheed. I'm not sure about this though, gvim might have never worked on my system yet.
I used dropbox because I can't post images on stackoverflow.
Thank you for your help
When I use MacVim, all the color schemes work and looks very rich in the window.
But when I fire up my Terminal and use Vi inside it, the color schemes look very very bad. Is there any setting/config I should set to let Terminal Vi use all the colors available by a color scheme.
Update: I use
MacOSX Lion
Terminal v2.2 with xterm-color
Vim 7.3
Thanks
You probably can't do this. It's not Vim's fault, it's your terminal's fault. The GUI has access to millions of colours and terminals generally have access to 256 (or much less, depending on your terminal). It just doesn't have the guts to show the same colours as the GUI version. That's also why all of the colour schemes for Vim have values for the GUI (e.g. guibg) and values for the terminal (e.g ctermbg). There's a GUI value for the powerful side, and a terminal value for the weak side.
This is one of the reasons why I only use the GUI version. You can easily marry the command line with Vim so that using a single GUI version is much easier. You can check out a video on how to do this at vimeo and I recently created a plugin for ZSH that makes it even easier, which you can get from Github
If configure your .vimrc with the command
set t_Co=256
you are configuring vim to allow colorschemes that use 256 colors. Maybe MacVim uses this configuration by default.
I'd advise trying CSApprox
On OS X especially you can get very good results for console Vim.
I use it on OS X, Debian & Fedora with good results for console Vim & Matt who wrote the plugin, is a very helpful guy & will do his best to get the best results possible for you if you run into problems.
I'm guessing lots of people get this problem, but I can't seem to find any other threads/questions about it anywhere. I guess it's difficult to capture in keywords.
Basically, Vim doesn't draw the background color when scrolling up in places where there is no text. I've also seen it on my friend's Mac, so it's not peculiar to my setup.
I have a pretty big vimrc, but I get the same problem without a vimrc and setting :colorscheme blue.
I'm using gnome-terminal on Ubuntu 11.10 (Oneiric Ocelot). It's a fairly clean install that I set up only a few days ago, so there's not really any funny business going on. I expect this would happen out of the box.
I've not had this problem in other contexts e.g. over SSH with PuTTY or previous versions of Ubuntu which I'm guessing was also gnome-terminal.
What's going on?
In Linux I had export TERM=xterm-256color in my .bashrc. That caused Vim to look like this (after setting set t_Co=256):
When I removed that line from my .bashrc and opened a new terminal (exec bash didn't do it). This is what I get (you need to have set t_Co=256):
Try running :set t_Co=256 (replacing 256 with the value corresponding to the number of colors your terminal supports). A similar looking (though less conspicuous) problem of mine was caused by using too few of the available terminal colors in Vim. To figure out how many colors your terminal supports, see this.
I had to do two things:
Remove set t_Co=256 in my .vimrc. (The terminal showed 256 colors anyway)
The color blocks still appeared when scrolling though, so I had to do the change detailed here: https://superuser.com/questions/457911/in-vim-background-color-changes-on-scrolling
I tend to maximize a terminal to one screen, and vertically split several windows in Vim. Everything works fine for the first few windows on the left, but clicking past about the 220th column in the terminal doesn't work correctly. Any mouse clicks past column 220 seem to be wrapping around to column 1. I've tested in xterm, urxvt, and Gnome terminal with and without tmux/screen; always the same behavior. If I greatly increase the size of the font in Gnome terminal, I can click on the last column (although it is no longer past column #220).
If I run a command in a terminal that prints to standard output, I can click all the way to the right of the terminal. The problem does seem to be related to Vim.
I have set mouse=a in .vimrc. I'll post the entire file on request, but it doesn't seem to have anything else related to the mouse.
It's probably irrelevant, but I'm running Xmonad+Gnome. Thanks in advance.
This has been fixed in Vim 7.3.632. See :h sgr-mouse. Or just put this in your ~/.vimrc:
set ttymouse=sgr
If you want to be compatible with versions that don't have mouse_sgr compiled in, use:
if has("mouse_sgr")
set ttymouse=sgr
else
set ttymouse=xterm2
end
To see if your version of Vim has mouse_sgr, run vim --version from the command-line, or in Vim, enter :version, and look for +mouse_sgr.
If you're using older versions of screen, or terminal emulators that don't support SGR, you may need to upgrade or switch. These settings work with all new versions of screen, tmux, gnome-terminal, PuTTY/KiTTY, iTerm2, and Terminal.app, using TERM=xterm-256color or screen-256color.
Update: If you're using neovim, SGR support is enabled by default.
Edit:
I deleted the bug report, as that tracker was for the website, not the text editor.
In looking in the correct place for an existing bug report, I found this:
http://groups.google.com/group/vim_dev/browse_thread/thread/4c137e64d2032441/b3993eaa89589619?lnk=gst&q=mouse#b3993eaa89589619
To summarize, it was an xterm limitation that has been lifted. However, Vim does not yet support columns longer than 223.
Original:
This seems to be a bug, as supported by comments made by redstreet. I filed a bug report:
https://sourceforge.net/tracker/?func=detail&aid=3389331&group_id=27891&atid=391887
A few years later, the bug still seems to be present.
The solution I found is neovim: a modern refactor of vim. Among other features, this bug has been resolved.
I simply copied my .vimrc into .nvimrc, and my plugins just worked with nvim. Maybe I'll just keep using that.
Something extremely weird is happening when I open files in vim, and I can't remember doing anything that would have caused it.
Weird behaviors include:
no text being visible until I highlight it in visual mode, at which point it is visible from thereon. ":redraw!" does not make anything visible.
line 1 missing
occasionally the cursor appears one line below where it is editing
statuses become permanent and scroll up from the bottom, rather than just redrawing at the bottom
the vim text not extending to the bottom of the vertically maximized window
I lack the reputation to post screenshots but I'll happily provide any other information that could help in a diagnosis.
ETA: Ah! My .vimrc specified a column/row size. I've removed that line, and so far things are behaving well. Thank you!
vim is terminal based, and errors like this happen when the terminal you are using does not match the terminal vim thinks you are using. Most people use vim with terminal emulators. This kind of thing can happen when you resize the emulator window and vim does not find out about it, or more rarely, when the terminal-identifying-string specified in the environment does not match the terminal emulator you are running.
Without more details about the platform on which you are running vim, it is hard to be more specific-- but as a tip: don't resize the emulator window after it is created but before running vim.
Terminal emulators are supposed to communicate size changes back to the program running within them, but this is not 100% foolproof, especially when you are logged in to a remote machine within the emulator.
If you're doing this from a UNIX (Linux et al), try running :!resize to force your terminal to re-adjust its size parameters. At the very least it'll tell you what the system thinks your window is sized to, which may not match its actual size.
I had a similar problem when using vim with bash. When I switched from bash to zsh, it gave redraw errors where, while I typed, the cursor or screen would appear to go down one row for every 10 characters I typed. Scrolling with arrow keys also caused major display problems along the same lines, but worse.
I had this line in my previous .vimrc, I believe it was to set the color for vim
set t_256
I changed it to set term=xterm=256color and the problem went away.