-
-
Notifications
You must be signed in to change notification settings - Fork 112
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
notcurses-info loses information in the scrollback on some terminals #2114
Comments
i'm not able to reproduce this in the exact manner you've specified, but i know this issue, or something close to it, exists. oh wait nevermind, that was kitty. let me get an 80x24 xterm...hrmm, same results. i have all expected output in my scrollback at 80x24 on XTerm 368:
i know about a possibly-related issue, however, which is that output scrolled out of the visual region between renders is never actually emitted to the screen. i'm not convinced that's an actual bug, but it probably is (this is along the lines of XTerm faithfully displaying all output when presented with a great amount of it, whereas other terminals will skip some (see the i don't think that would lead to the situation you're seeing, though. in fact, i'm not sure what could. it looks like the lost text is from the first run. what happens if you run thanks for this report. i expect it will require some investigation. |
In retrospect, you're probably just using the |
Yeah, XTerm doesn't have the problem - it's only on Konsole and VTE-based terminals like Gnome Terminal. |
That doesn't trigger it. Assumedly because it's just scrolling with a linefeed rather than an An easy way to tell whether a terminal will be affected is with a command like this:
If you scroll up and see a break in the sequence, you know the terminal has this bug. |
i am absolutely using |
I think I misled you by putting the
If you're doing that, I think xterm.js may be another library with this problem that's worth addressing. At least I was seeing this behavior in the Hyper terminal, which I believe is using xterm.js. And Windows Terminal also has this issue, but I'll probably file a PR for that myself, or at least raise an issue for it. While I kind of prefer the VTE interpretation myself, if we're going to set our |
oooh that's a really good subtle point, let me go change that |
ahhh, that makes things clear, thank you. ok, i will ponder this. thanks as always for the quality writeup and analysis! |
ok, i think i might understand what's going on here now (haven't reread, but had an insight while looking at some code).
so if you for instance ran i think that's the problem this issue describes; if not, we need go file this somewhere. |
Fitting on screen isn't the problem - at least that's not the problem I'm complaing about. Let's say your screen is 37 lines high, which should be plenty of space for If you run Terminals that preserve the entire file include XTerm, MLTerm, and Alacritty, while terminals that lose part of the file include Gnome Terminal, Konsole, and Windows Terminal. I'm of the opinion that the latter group is in error, and this is really their problem to fix, but you may still want to try and avoid the situation if you can. |
Steps to reproduce:
From what I can make out, notcurses-info seems to be using the
SU
escape sequence for something, which is problematic. While some terminals will pan the viewport down, in the same way as a linefeed at the bottom of the page, some will merely scroll the content of the buffer, which has the same effect as deleting lines from the top of the window (thus losing content you might expect to see in the scrollback).I'm assuming you want the viewport to pan down, which is probably the most common interpretation in Linux terminals, but both Konsole and VTE have gone with the buffer scrolling interpretation instead. So unless you can at least persuade VTE to change their behaviour, it may be a good idea to avoid scrolling like this.
The text was updated successfully, but these errors were encountered: