-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
std.Progress
: fix inaccurate line truncation and use optimal max terminal width
#12079
Conversation
So FreeBSD doesn't have termios which I use to get the terminal width... Or maybe FreeBSD does have it but we just don't have the things exposed in https://github.com/ziglang/zig/blob/master/lib/std/c/freebsd.zig? I've limited it to Linux (and Windows) for now. Good enough for a start. |
8a14b3e
to
ab67938
Compare
fe9e35a
to
70b6ac3
Compare
70b6ac3
to
fd29865
Compare
Currently, the code assumes a terminal width of 100. If we look at what's printed for the last test: ``` Test [1/1] test "basic functionality"... [101/100] this is a really long name designed to activate the truncation code. let's fi... ``` No, it does not really work because the relevant part here is `"[101/100] this is a really long name designed to activate the truncation code. let's fi... "`, which is 90 characters, but we expect 100 because that's the width that is assumed. The reason is that it also measures **unprintable characters** (escape sequences) at least non-Windows systems. With this commit the output is now: ``` Test [1/1] test "basic functionality"... [101/100] this is a really long name designed to activate the truncation code. let's find out if... ``` Of which `"[101/100] this is a really long name designed to activate the truncation code. let's find out if... "` is the actual output of *our* `std.Progress` (remember that `zig test` has an `std.Progress` and our test itself does). The length of that string is 100. Now the length is consistent with Windows where we don't use escape sequences. This issue was only present on non-Windows systems.
This is done by 1. getting the current terminal width and 2. subtracting that by the current cursor column. This accounts for previous output from someone else.
They make it easier to see how the progress line is printed in different cases.
It also expands an acronym used as a variable name. It confused me.
fd29865
to
cbdb29d
Compare
Thanks for the deep dive into this problem! |
Yes, this behavior is as expected. The main problem I focused on to solve here was the one you originally described where if the line goes beyond the end of the terminal then the output becomes malformed. Resizing the terminal while progress is being printed and then the output becoming malformed is a different, probably more difficult problem. It's because Line 179 in 0eb3b8f
So after that we don't recalculate any values based on the terminal width. Well, it's only really max_width that we have to calculate based on terminal width and cursor position.
It seems I talked a bit about it in #12024 (comment) as well. There are two ways I can think of that may be useful here for attempting to fix this:
I did try to put a Line 286 in 0eb3b8f but I couldn't really notice a difference. It certainly didn't fix that issue you're describing. Maybe we can come up with a way to fix this someday. Another thing we could do of course is enabling the terminal's alternate screen buffer which would give us full control and then we could just clear the screen if the terminal is resized. |
I have noticed this causing my terminal to stop accepting input sometimes. The previous implementation with all of its flaws was better in the sense that it never caused this to happen. This commit has multiple reverts in it: Revert "Merge pull request #13148 from r00ster91/progressfollowup" This reverts commit cb257d5, reversing changes made to f5f28e0. Revert "`std.Progress`: fix inaccurate line truncation and use optimal max terminal width (#12079)" This reverts commit cd3d8f3.
I really had a lot of attempts at this and I think this might be the best one so far. I think there's still some things to improve but this is definitely a start.
Output now fits nicely on pretty much any terminal width (well, not if it's >256 though, but that limit can easily be bumped):
Here's another common issue that I think Andrew described in #12024 (comment):
That issue seems to be fixed now; here's a compilation on a terminal with a very small width:
2022-07-11.20-05-03.mp4
It succeeds with nothing left on the terminal.
Closes #12024