Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Background color gets broken on large command output #10444

Closed
willeccles opened this issue Jun 17, 2021 · 6 comments
Closed

Background color gets broken on large command output #10444

willeccles opened this issue Jun 17, 2021 · 6 comments
Labels
Needs-Attention The core contributors need to come back around and look at this ASAP. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.

Comments

@willeccles
Copy link

Windows Terminal version (or Windows build number)

1.8.1521.0

Other Software

WSL2 + Void Linux
zsh shell (5.8)
Seems most frequent when using Neovim (not during, but maybe after?), GCC, clang, etc.

My configs for zsh, nvim, vim, etc. can be found here. My WT settings are attached (zipped because GitHub; note that I am almost always using my Void config, I don't use the others frequently enough to know if this happens there).

settings.zip

Steps to reproduce

Simply run a command which produces a lot of output. It's not consistent, but I can reproduce it frequently when a program's output is very long and all comes out at once (or extremely quickly, anyway). This often includes things like C++ compilers giving lots of notes, my own programs dumping a lot of debug logs (at the moment, a C++ program parsing a large JSON file and printing the parsed data), etc.

Expected Behavior

The program's output should just be there as you'd normally expect:
image
I have added the output line count for reference, though it's likely not super useful here.

Actual Behavior

Ironically I'm struggling to reproduce it at the moment, but what happens is that the background color after a newline character (i.e. at the end of each line, all the way to the right of the window, but not during the line's content itself) changes to a lighter one. I will see if I can figure out what actual steps seem to make this happen the most. Additionally, resizing the window seems to fix it (although it causes other issues with my shell's output, but that seems likely to be more related to the shell, or at the very least out of the scope of this issue). I normally use one window maximized (not fullscreen) with multiple tabs.

I will update with a screenshot the next time it happens (which should be about 10 seconds after I click "Submit", knowing how software works).

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Jun 17, 2021
@DHowett
Copy link
Member

DHowett commented Jun 17, 2021

Let us know if you can reproduce it and what led to that state! Some of this is likely by design -- the terminal is supposed to take on the background color that was present at the end of the line at the bottom of the viewport, but it may not do so consistently.

@DHowett DHowett added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jun 17, 2021
@willeccles
Copy link
Author

Absolutely will! I'll see if I can't get it to happen tomorrow--had to work on other stuff today, so I didn't get to do as much testing as I wanted.

@ghost ghost added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Jun 18, 2021
@j4james
Copy link
Collaborator

j4james commented Jun 20, 2021

This might be related to #8823. That issue also had the background color changing on end of the line (and it doesn't happen all the time).

@willeccles
Copy link
Author

Yes, I think that this is most definitely related. That seems to be about the behavior I'm seeing.

@willeccles
Copy link
Author

I have been unable to reproduce the issue (unsurprisingly, because nothing ever goes wrong when you need it to), and I am almost certain that #8823 is the same issue. I will close this issue for now, and if I can find some evidence to suggest they are different issues, I will reopen. For the time being, it's probably best to avoid the duplicate issue.

@DHowett
Copy link
Member

DHowett commented Jun 22, 2021

Thanks for following up 😄 If it ends up being different, feel free to reopen or open anew!

@DHowett DHowett added the Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. label Jun 22, 2021
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Jun 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs-Attention The core contributors need to come back around and look at this ASAP. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Projects
None yet
Development

No branches or pull requests

3 participants