Neovim: Bleeding characters + color-codes on split scrolling

[alexozer]

It appears that scrolling a vertical split can sometimes cause characters and color-codes to "bleed out" on the left side of the terminal. Here's a little demo, and this is the file I was testing with. The effect seems greater when there are either more characters in a split (with a more "dense" file and/or smaller font), when the split is scrolled more quickly, or both.

I have tested with gnome-terminal, st, and xfce4-terminal, and it occurs in all of them, so I don't think the terminal is at fault. I've also managed to reproduce this with an empty init.vim.

[synaptiko]

I've noticed similar thing recently but when switching between tabs...

[justinmk]

Please say your $TERM

[synaptiko]

$TERM=gnome-256color and I'm using gnome-terminal 3.18.2-1 on ArchLinux

[justinmk]

Does the behavior change if you export TERM=xterm-256color before running nvim ?

[alexozer]

The behavior remains the same for me when running export TERM=xterm-256color before nvim (on gnome-terminal 3.18.2-1 + Arch)

[justinmk]

@synaptiko @alexozer Do you have $COLORTERM set and if so can you try without it?

[alexozer]

I don't have $COLORTERM set.

[synaptiko]

@justinmk I also don't have $COLORTERM set and with xterm-256color it's the same.

[synaptiko]

Btw. it's not happening under Guake, but in Gnome Terminal it is.

[alexozer]

@synaptiko I was actually able to reproduce it with Guake. Have you tried scrolling with the test file and a small font?

[synaptiko]

@alexozer Yes, with various font-sizes. I tried both TERM=gnome-256color nvim and TERM=xterm-256color nvim. So for me Guake seems to be working without any issue.

[alexozer]

@synaptiko Here's a screencast of my experience with guake

[synaptiko]

@alexozer Ok, I have to take it back. When I open three vertical splits as it's in your screencast then it starts happening again.

[FuzzOli87]

I see the same thing that @synaptiko sees on terminator-gtk3-bz on Arch. I'm using

let $NVIM_TUI_ENABLE_TRUE_COLOR=1
let $NVIM_TUI_ENABLE_CURSOR_SHAPE=1

I'm using oceanic-next true color scheme. No particular action triggers it. Just happens every once in a while.

[justinmk]

All terminals reported above are libvte terminals[1], including guake. What version of libvte are you using?

1. https://gist.github.com/XVilka/8346728#now-supporting-truecolour

[alexozer]

Also, in case it wasn't apparent, this behavior does not occur in normal
Vim.

[synaptiko]

@justinmk I'm using:

• libvterm 0.1.git1.c4317a6-2
• vte 0.28.2-7
• vte-common 0.42.1-2
• vte3 0.42.1-2

[alexozer]

@justinmk I just tested on xterm, a non-VTE terminal, and still experienced the bug:

[justinmk]

Hmm, I wonder if it's a terminfo issue.

Is anyone _not_ having this issue on linux?

[wsdjeg]

can not reproduce,what is the step?

[crondog]

@justinmk I am using Arch linux and this does not affect me (nvim v0.1.2-265-gdddbf9c). I tested with termite (vte) and st

However in termite where ex commands go, I notice a flash of ~@k or <80> but then they disappear. The same for st but instead it is ^Y and ^E which are the codes for mouse scroll up/down. This only happens when I scroll really fast though and only sometimes

[fbernier]

I have an issue which looks similar to @synaptiko. I tried recording an asciicast, but the problem does not appear in it -_-

https://asciinema.org/a/96b3b4vlrcmc79kmmwedxcfsl

Here is a screenshot of what actually appears in the status line:

http://i.imgur.com/qMR5jV9.png

Using Arch + guake terminal, xterm-256color.

[FuzzOli87]

Started using Terminix recently and it's showing the same issues.

[FuzzOli87]

This is also happening on my mac on the nightly version of iTerm2. I'm still not sure what triggers it but it does become pretty annoying and distracting, especially when this happens on actual code lines and I'm forced to close the editor and start over. Happens too many times for comfort.

[rvolosatovs]

• Arch linux
• Termite
• Neovim 0.1.4

It is kind of weird, but the issue appeared the same day I switched to a 4k screen. Have never encountered it before. Can it be anyhow related?(the software did not change during the switch)

Does not happen often, mostly after opening a new buffer. Fixed by a scroll up/down.

[wasowski]

I used to see this problem in the past a lot, but recently not at all on Ubuntu --- presently NVIM 0.1.5-dev, gnome-terminal 3.18.3 and this script. Don't really have time on my hands to debug why, but perhaps someone else can see what is fixing this.

The nvim-wrapper script is available online, but I include the gist to ensure that the actually working version is available here. I have not written that script.

For the record I use both 4K and regular screens, so I doubt that this is related. It is likely some terminal compatibility issue.

[justinmk]

@wasowski Without the wrapper script, the problem still occurs for you?

[wasowski]

Very good point @justinmk . Just tested with the same gnome-terminal and it does not. So the script is a red herring, ignore it.

[ikouchiha47]

happens with me in a normal gnome-terminal as well. as well as in rxvt and sakura. I wonder what is wrong. then again if I resize the terminal, it becomes ok, (this is rxvt).. same with the terminal wrapper.

maybe gnome is just bad.. -_-

[romgrk]

On terminix:

[raichoo]

I've been living with this for approximately a year now and it's getting a bit frustrating… is there any more information that can be provided to pin this down?

[justinmk]

@raichoo Did you try different terminals or maybe a different $TERM? This is most likely a bad interaction with unibilium or a bug in our screen code.

A reduced test case would help a lot. So far I see a bunch of screenshots of a problem I've never encountered on all kinds of systems. Except I don't use gnome.

[raichoo]

@justinmk There is a way I can reproduce this: I'm using gnome-terminal. TERM=xterm-256color.

1. open terminal
2. switch terminal to gnome full screen
3. open a highly colorful file (e.g. CMakeLists.txt from the neovim tree)
4. do a vertical split so the same file shows up in the split
5. stay in the left split
6. press C-l
7. if no strange character appears in the right split go to the next line. goto 6.

I've also compiled a minimal init.vim to reproduce the error.

set rtp+=~/.nvim/plugged/molokai
set termguicolors
set listchars=eol:¬
set number
set list

color molokai

nnoremap <silent> <C-l> :noh<CR><C-l>

It seems to be a combination of these features that trigger the bug. At least on my machine.

[justinmk]

So without the listchars setting it does not happen? Is everyone else here using a Unicode listchars setting?

[raichoo]

I've tried it with a non-unicide eol listchar and the bug didn't occur. I'm not sure if this is what triggers the bug for everyone else, I'm not even sure if this is the only configuration that triggers it, but it's perfectly reproducible on my machine.

[justinmk]

Perhaps related to drawing Unicode cells in general. Some length calculation may be off.

[raichoo]

That sounds like a possibility. I also see unicode listchars in the screenshot that @romgrk made.

[raichoo]

Hm, I've tried working with number, list and listchars turned off and the bug still showed up. I guess we can rule out listchars as well as number.
I didn't use the minimal .vimrc though but my regular config with these options turned off.

[raichoo]

I have managed to reproduce the bug with a file that heavily uses Unicode while using the minimal vimrc with listchars, list and number turned off.

syntax on
set rtp+=~/.nvim/plugged/molokai
set termguicolors
"set listchars=eol:¬
" set number
"set list

color molokai

nnoremap <silent> <C-l> :noh<CR><C-l>

I've opened a bunch of splits set the filetype to haskell and moved around pressing C-l on every one. This configuration resulted on the weird character in the right split when I pressed C-l on line 7 in the left split.
I don't know if this is related to Unicode though, it might just lead to the bug being triggered more often.

[raichoo]

I could also reproduce this error using the desert colorscheme, haven't managed to do so with default.

So the current minimal test case is

syntax on
set termguicolors

color desert

nnoremap <silent> <C-l> :noh<CR><C-l>

The test file I'm currently using is taken from the Agda stdlib (with filetype set to haskell)

------------------------------------------------------------------------
-- The Agda standard library
--
-- Lists where all elements satisfy a given property
------------------------------------------------------------------------

module Data.List.All where

open import Data.List.Base as List hiding (map; all)
open import Data.List.Any as Any using (here; there)
open Any.Membership-≡ using (_∈_; _⊆_)
open import Function
open import Level
open import Relation.Nullary
import Relation.Nullary.Decidable as Dec
open import Relation.Unary using (Decidable) renaming (_⊆_ to _⋐_)
open import Relation.Binary.PropositionalEquality

-- All P xs means that all elements in xs satisfy P.

infixr 5 _∷_

data All {a p} {A : Set a}
         (P : A → Set p) : List A → Set (p ⊔ a) where
  []  : All P []
  _∷_ : ∀ {x xs} (px : P x) (pxs : All P xs) → All P (x ∷ xs)

head : ∀ {a p} {A : Set a} {P : A → Set p} {x xs} →
       All P (x ∷ xs) → P x
head (px ∷ pxs) = px

tail : ∀ {a p} {A : Set a} {P : A → Set p} {x xs} →
       All P (x ∷ xs) → All P xs
tail (px ∷ pxs) = pxs

lookup : ∀ {a p} {A : Set a} {P : A → Set p} {xs : List A} →
         All P xs → (∀ {x : A} → x ∈ xs → P x)
lookup []         ()
lookup (px ∷ pxs) (here refl)  = px
lookup (px ∷ pxs) (there x∈xs) = lookup pxs x∈xs

tabulate : ∀ {a p} {A : Set a} {P : A → Set p} {xs} →
           (∀ {x} → x ∈ xs → P x) → All P xs
tabulate {xs = []}     hyp = []
tabulate {xs = x ∷ xs} hyp = hyp (here refl) ∷ tabulate (hyp ∘ there)

map : ∀ {a p q} {A : Set a} {P : A → Set p} {Q : A → Set q} →
      P ⋐ Q → All P ⋐ All Q
map g []         = []
map g (px ∷ pxs) = g px ∷ map g pxs

all : ∀ {a p} {A : Set a} {P : A → Set p} →
      Decidable P → Decidable (All P)
all p []       = yes []
all p (x ∷ xs) with p x
all p (x ∷ xs) | yes px = Dec.map′ (_∷_ px) tail (all p xs)
all p (x ∷ xs) | no ¬px = no (¬px ∘ head)

[raichoo]

I've checked this with an ASCII file and I could reproduce it as well, so this seems to be pointing to a problem with termguicolors and more elaborate colorschemes.

[romgrk]

To extend the minimal test case described above, if the following line in the desert.vim colorscheme

hi Normal   guifg=White guibg=grey20

is changed to

hi Normal   guifg=White

the issue disappears.

Edit: aka :colors default | hi Normal guibg=grey20 triggers the issue.

[raichoo]

I've added highlight Normal guifg=White guibg=None to my init.vim and I haven't seen the issue for a day now (which is a really good sign). Maybe it just decreases the chance of the bug showing up but I will continue to monitor this over the course of the next week.

[ghost]

getting this as well, it seems pretty random although this happens mostly when i have nvim opened in terminator with xterm in the far left side of the screen.

opening ex mode and hitting backspace makes this worse.

tried removing all plugins, (with same init.vim) and this still happens.

[sherzinger]

I'm getting this as well, but only on external displays. (s. closed issue above)
The workaround does not work for me.

[ghost]

it seems i'm not getting this anymore after removing this from init.vim
highlight ColorColumn ctermbg=80
but again this maybe just luck cause this issue happens pretty randomly for me.

edit: nope i'ts not the highlighting, this happend to me again after resizing the terminator split window
and hitting backspace on ex mode.

[YorickPeterse]

I ran into this as well, but only a few times. In my case Neomake adds a bunch of Unicode characters on lines that contain warnings and such. Switching those characters over to pure ASCII characters thus far seems to solve the problem.

[justinmk]

5436 may help this issue, if someone here can try latest master.

[sherzinger]

I can confirm that the issue is solved for me.
Awesome, thanks!

[justinmk]

Closing this. Will re-open if someone reports differently.

[allyraza]

I am also having this problem, every issue that has been reported with this behavior has been closed, why not reproduce it and fix, I did fresh xubuntu this issue creeps up

[curvi]

I have these bugs for way more than a year. I use the most recent Ubuntu build 0.2.1-dev and the most recent fedora build both on Gnome Terminal and get these fragments and "bleeding" on various Laptops/Display/Linux combinations!
It seems to have something to do with fullscreen/window resize, other than that I cannot specify as much as I would like.
Please fix this - this makes nvim a real bummer to use!

[justinmk]

@curvi This issue is not a catch-all for general complaints about display issues.

[sherzinger]

@justinmk Is there open issue related to this one or can we maybe re-open it?
This bleeding appears again quite frequently for me. It's especially notable in large files when scrolling via <C-d> and <C-u>

(Using v0.2.2 on macOS 10.13.1)

[alefa]

I'm experiencing this issue as well (i.e. bleeding characters when scrolling in a vertical split). It's pretty annoying. If there's no other open bug report on this issue, can we reopen this one as @sherzinger suggested?
I'm on Debian 9 with Neovim 0.2.2 compiled from source.

[justinmk]

@alefa This issue regressed in 0.2.2, it's fixed again on 0.2.3 (the development version). See https://github.com/neovim/neovim/pull/7676

The Releases page has pre-built archives for Linux/Windows/macOS. (No installation needed, just unzip and run. For Linux, nvim.appimage is a universal "binary", just chmod u+x nvim.appimage && ./nvim.appimage)