Closed jasin closed 6 years ago
You could fire up sshd and log in to it with PuTTY or similar and see if the same background problem continues. If it works okay in a terminal but not in the console, then this is a console issue...
Work continues to make the console work more and more like a terminal...
@jasin What windows build# are you on? There was a bit of churn in that area recently. I think I already fixed that, but if not, knowing the specific build number will help me track it down.
@zadjii-msft Windows Version 10.0.16299 Build 16299
@jasin could you post what the following python script looks like when you run it in the console?
import sys
import time
def csi(seq):
sys.stdout.write('\x1b[{}'.format(seq))
def write(s):
sys.stdout.write(s)
if __name__ == '__main__':
print('Clearing the line paints to the end?')
print('\E[42mfoo\E[43m\E[KTest')
csi('42m')
write('foo')
csi('43m')
csi('K')
write('Test')
csi('m')
print('')
print('\E[42mfoo\E[43m\E[K\\nTest')
csi('42m')
write('foo')
csi('43m')
csi('K')
write('\nTest')
csi('m')
print('')
print('\E[42mfoo\E[43m\E[1KTest')
csi('42m')
write('foo')
csi('43m')
csi('1K')
write('Test')
csi('m')
print('')
print('\E[42mfoo\E[43m\E[1K\\nTest')
csi('42m')
write('foo')
csi('43m')
csi('1K')
write('\nTest')
csi('m')
print('')
print('\E[42mfoo\E[43m\E[2KTest')
csi('42m')
write('foo')
csi('43m')
csi('2K')
write('Test')
csi('m')
print('')
print('\E[42mfoo\E[43m\E[2K\\nTest')
csi('42m')
write('foo')
csi('43m')
csi('2K')
write('\nTest')
csi('m')
print('')
print("\x1b[48;2;64;128;255mX\x1b[48;2;128;128;255m\x1b[KX")
csi('m')
print('')
You can just paste that into a file like gh2710.py
and run it with python gh2710.py
Hope this helps
Welp, that's exactly how that's supposed to look. Shoot. This must be some other weirdness then.
Just to help investigate, are there any specific plugins you have installed? Have you modified your neovim configuration at all? (I'm not really familiar with neovim, but for normal vim I'm talking about the .vimrc file)
I'll file a bug on my end to make sure this gets tracked down.
Well I am not sure I fully understand the problem so it seems.
I was using neovim during an ssh session to my FreeBSD box. That is where I do my development. I decided to quickly install the neovim package from the unstable ppa and I do not see the issue locally that I am experiencing during an ssh session to my FreeBSD box. I do run zsh shell on that server box.
To note, I did run the py scrypt on my FreeBSD box through ssh session and you said that looked ok, so this must specifically be a neovim/FreeBSD issue over SSH. But that is as far as I am willing to comment. I'm not sure I know enough to look into it further without some possible clues.
Further investigation shows this is not just limited to neovim, I see the issue in vim as well over SSH to FreeBSD, but slightly different, opening up a file now shows me this without even having to scroll. I have also ruled out the shell, makes no difference, didn't think it would, but I double checked using bash shell
@jasin can you post the output of infocmp
on your FreeBSD machine?
Here you go
jasin:tyr~$ infocmp
# Reconstructed via infocmp from file: /usr/local/share/misc/terminfo.db
xterm-256color|xterm with 256 colors,
am, bce, ccc, km, mc5i, mir, msgr, npc, xenl,
colors#0x100, cols#80, it#8, lines#24, pairs#0x7fff,
acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=\r,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H,
hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
il=\E[%p1%dL, il1=\E[L, ind=\n, indn=\E[%p1%dS,
initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~,
kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D,
kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=^H,
kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q,
kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~,
kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~,
kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~,
kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q,
kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El,
memu=\Em, oc=\E]104\007, op=\E[39;49m, rc=\E8,
rep=%p1%c\E[%p2%{1}%-%db, rev=\E[7m, ri=\EM,
rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, rmam=\E[?7l,
rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E>,
rmm=\E[?1034l, rmso=\E[27m, rmul=\E[24m,
rs1=\Ec\E]104\007, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,
setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
smcup=\E[?1049h, smir=\E[4h, smkx=\E[?1h\E=,
smm=\E[?1034h, smso=\E[7m, smul=\E[4m, tbc=\E[3g,
u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?%[;0123456789]c,
u9=\E[c, vpa=\E[%i%p1%dd,
I can confirm this bug in Ubuntu 16.04 after Fall Creators update and via SSH to FreeNAS (FreeBSD). When scrolling, the background color (in this case grey) disappears where there is no text. Both in Vim and Neovim. This makes it impossible to use sophisticated color schemes in Vim/Neovim:
I don't know why #1706 is locked? It is still very valid and describes the bug well.
Okay yea I'm seeing this again.
To limit the repro variables for myself:
let g:solarized_termcolors=256
colo solarized
:redraw!
will get the whole buffer looking right, and then any scroll up down will only have the right bg filling the top or bottom line
I too confirm this bug in my system:
I've tried every suggested methods of #1706 , still while scrolling down the entire color-scheme sort of fades out, turns colorless as we can see below.
I got this figured out. I was off-by-one on copying the RGB attributes of the last run of characters.
Before:
After:
gnome-terminal (for reference):
I'm gonna add some tests and get this code reviewed. Thanks for all the persistence and patience folks!
This issue was moved to Microsoft/console#70
As of today, with the latest Windows Insiders build, the fade away issue while scrolling has been resolved but still there's this ugly grey bar masking every text in the document while the color stays intact.
- Operating System and version: Windows 10 Pro Insider Preview / Version: 1709 / OS-BUILD: 17074.1002
- Ubuntu 16.04.03 LTS
- VIM- Vi IMproved 8.0 (2016 Sep 12, compiled Jan 02 2017)
This is a similar problem to the one listed here, but since someone decided to lock that thread I'll start my own.
1706
@zadjii-msft
Simply put, I am running ubuntu from the windows store
lsb_release -a returns 16.04.3 LTS
You can see the problem in neovim, when the file is scrolled down the background color is stripped. I have no idea if this problem has been fixed in 16.04.3 LTS or if this is only fixed in the insider version?? Any sort of tips on how I can further look into the problem I'd happy to look into it and report back.