warpdotdev
Unable to pause scroll
Discord username (optional)
No response
Describe the bug
When a command is running which outputs a lot of logs, the text scrolls very quickly. I like to be able to read some samples of what is going on. To do that on iTerm, I scroll up and then I'm removed from autoscroll-mode. I can then calmly scroll up and down the still text. Below where I'm reading, new logs are continuing to be generated and so my scrollbar is continually moving up slowly as my relative position in the logs changes. If at some point my position reaches the top then yes, my text will scroll off the terminal and I'll basically be looking at the head (as opposed to the tail) of the autoscrolling logs. Am I making sense? Effectively I just want to be able to read quickly scrolling logs. In Warp though, when I scroll up from the "tail" of the logs, the text continues to scroll past me just as quickly. This is because my relative scroll position in the terminal remains fixed.
To Reproduce
Steps to reproduce:
- Generate a lot of logs
- Scroll up
Expected behaviour
Relative scroll position should move so that the text does not move.
Screenshots
a video would be more help but I can't be bothered.
Operating System
No response
OS Version
666
Shell Version
666
Additional context
No response
Warp Internal (ignore): linear-label:24888f54-df93-45d5-9bdd-e38f740cac19
No response
Experimented with this a bit. It seems that when the output is produced rapidly, it's hard to scroll up and read a particular line. But when the output is not produced as quickly, this seems to work well today. Here's a repro:
# produce_output.py
from time import sleep
i = 0
while True:
print(f"THIS IS LINE i={i}")
i += 1
# Without this sleep, it becomes impossible to read data at
# a fixed position line. With the sleep however, scrolling
# to some part in the already-produced output seems to work
# well.
sleep(0.1)
Came here to file this bug. Enjoying the terminal - today's use case I was executing a long-running batch job interactively and I was unable to copy/paste output for debugging. I'm aware I could send to background, but I also need the full log for other purposes so I get to watch it scroll in entirety.
Ideally, I would like to be able to pause the buffer at the current location for introspection, and then once finished advance back to the latest stream. Even when I scroll back, the buffer is moving around and adjusting my relative location in the output stream to the viewing buffer.
Hopefully this context makes sense.
v0.2022.05.16.09.01.stable_01
would love to pause logs as it is difficult to pinpoint to problems of running application
This is quite an important feature. It seems like the problem is only really happening when there are lots of logs very quickly and the maximum block length is reached. Lines seem to be removed from the beginning of the block, causing data loss and this bug. Is it a performance tradeoff?
Bump - this is basically the only case where iTerm 2 is better for me than Warp. When I attach to logs of a Docker container, it's impossible to stop the automatic scroll behavior to pause and read some logs while new ones keep coming in.
Agreed. This and #610, which seem to be tightly related, are real blockers for using Warp. I'm hoping with the recent comment in that ticket that it will be worked on, that this one will be fixed in tandem.
So, part of the issue here might be that we currently limit the length of a block to 10k lines - this is due to performance issues, and we've got an engineer actively working on resolving those so that we can raise the limit/let users set it to values in the millions.
Would that be sufficient to address the concerns here? Or does iTerm do anything fancy like stop reading output from the shell (effectively halting the running process) if you've paused auto-scroll but the output has reached the maximum line limit?
@vorporeal So what iTerm does, is if you are at the top or bottom of an ongoing scrollback, you will see the lines being added (at the bottom), and removed (at the top), so scrolling by however fast they are being created, but when you are in the middle, your view remains static on the lines in your view, with lines being added below your current view, and being removed above it, until you run out of scroll back buffer. This in practice means, that once you detach from the bottom, to look at a set of lines, then scroll bar on the right will slide up, showing where you are in the scroll back buffer.
Because of how Warp is handling its scrolling with blocks, no matter where you are in the scroll, if lines are being truncated, you can never get lines to stop - because they are sliding by 'in the block', and the scroll is relative to the block container (I think).
Since I don't know if that all makes sense, I made this short screen capture of iTerm, that hopefully makes sense.
+1 this is a blocker preventing from switching totally from iterm to warp.
I completely switched to Warp, but after facing this issue, I had to fall back.
Same here. I really enjoy Warp. But this feature makes me return to iTerm.
Sorry for the delays here; I've watched the above video and understand the scrolling issue being described! I'm aiming to work on improving this soon, hopefully next week.
+1 really enjoyed warp so far, but this is a very painful issue. Any updates on a fix?
I have a working prototype that ties the scroll position to a line in a block (as @ericmerrill was describing), but still need to figure out a small issue leading to occasional jitter. Aiming to get that done and launched in the next week or two!
This has been put on the back burner for now, but we'll post any updates/progress on this thread if/when we have them. Appreciate your patience folks!
I love Warp, but I'm also on the verge of moving back to iTerm as this issue ruins my user experience
Also having this issue with a long-running Python task. Would appreciate a fix!
This is a huge issue for my workflow. I'll have to switch back to iTerm for now.
I love Warp, but this thing makes me want to search for an alternative. It's very annoying to limit the number of lines where we have to look for live production logs.
Same issue with a GO service printing a lot of logs... it's very frustrating to not be able to have enough time to select intereting logs to at least copy them... Switching back to iTerm2 until this is fixed...
iterm + fig + atuin is a pretty great replacement. Not sure if I'll be returning to warp after finding this combo.
Gonna close this in favor of #610 --which is the root issue of this problem
uhhh seriously you can't make logs stop scrolling? I thought for sure it was my fault, goodbye warp
