Repository navigation
Feature Request: Pause output or scrolling on click (and make it a setting) #980
Description
See also #408
Reacted by Dan Thompson, Giovanni Bassi, Ignacio Buioli, Matthew Leibowitz, Kunal Pathak, Leonid Tsarev, Albert Ziegenhagel, Gary Oberbrunner, Nico, Taylor York and 6 more
Metadata
Metadata
Assignees
Labels
Issues related to settings and customizability, for console or terminalIssues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.)Complex enough to require an in depth planning process and actual budgeted, scheduled work.The new Windows Terminal.Fix is checked in, but it might be 3-4 weeks until a release.
Activity
DHowett-MSFT commentedon May 24, 2019
This will first require us to implement "pause output on click" ;)
zadjii-msft commentedon May 24, 2019
Oh man I thought we already did that by default. 🥚 🤕
binarycrusader commentedon May 24, 2019
Only downside is that this interferes with copy/paste. I wonder if the real ask here is not so much to disable pausing output as it is to disable scrolling while the user is attempting to copy/paste.
Personally, that's my biggest gripe about windbg and other tools is that I want execution to continue on, I just want to be able to select text to copy out while it's still busy executing and to not automatically scroll the window while I'm doing that.
My recollection is that a typical *NIX terminal works that way (or can anyway).
DHowett-MSFT commentedon May 28, 2019
Marking as Issue-Feature -- we need to figure out how to work out pausing scrolling with or without infinite scrollback; since we can't figure that out in the four minutes during triage, this beggars further discussion.
[-]Feature Request: Add a setting to disable pausing output on click[/-][+]Feature Request: Add a setting to disable pausing output or scrolling on click[/+]28 remaining items
frankseide commentedon Mar 31, 2020
DHowett-MSFT commentedon Mar 31, 2020
Frank Seide (@frankseide) Just to be clear, are you referring to the scrollback thumb staying in place and getting smaller, or the terminal completely pausing and ignoring output from applications (and deadlocking those applications until the user stops selecting)? Because when you say basics, we are going to need to get absolutely crystal clear about what you consider "basics".
DHowett-MSFT commentedon Mar 31, 2020
Just to add an additional point of clarification: "rewritten" is not the correct term here. The Terminal's text buffer implementation is shared with conhost, which doesn't support infinite scrollback or scrollback position locking when the buffer gets too long and items have to be pushed out of it... so there's nothing that was lost, or needs to be rediscovered, in our transition to Terminal.
tovine commentedon Apr 1, 2020
There's nothing wrong with the terminal being scrolled a bit down when you've reached the top of the scrollback buffer and new output is produced (that's understandable, you don't have infinite buffer), even gnome terminal does this. 😄
Although if you're able to adopt the same behavior as gnome terminal (and other similar ones), while avoiding the output being scrolled away when you're at the scrollback top (by pausing output if the buffer is full and you're at the top; as long as it's optional), that might actually be an opportunity for you to become the leading terminal implementation... 😮
kived commentedon May 28, 2020
I would just like it if Terminal worked the same as virtually all other terminal applications - if I scroll up, programs continue running but my scroll position is fixed to the output I'm looking at. It's almost not even worth having a scroll bar when the text continues moving after you scroll up.
frankseide commentedon May 28, 2020
Another example of this is are the built-in output panes in Visual Studio. When at the end, they keep scrolling. When the last line is not visible, they stay put, so that I can read what's there.
Add a spec for output snapping (#2529)
Implement preventing auto-scroll on new output (#6062)
garyo commentedon Jul 26, 2020
Sadly, this does not actually seem to be completely fixed.
What is fixed is that the terminal window doesn't scroll to the bottom on new output -- that's great.
But what's still broken is that if you're looking at some text back a few hundred lines, and then some output comes out (from your long-running build, say), the terminal still scrolls forward (upward) as you're trying to read.
It should stay "where it is", i.e. the same screen of text should remain visible, when you're not at the end, even when more output comes out. (Unless of course it can't, because the text you're trying to read is no longer in the scrollback buffer.)
What it appears to do is stay N lines up from the end. What it should do (IMHO) is stay M lines down from the top.
Tested with 1.2.2022.0 by running a long-running build, and scrolling back while it's building. You can use
while true; do echo hi there; sleep 1; doneto repro in a Linux shell.iamahumanbeing commentedon Aug 1, 2020
It is actually more subtle than what is described in #980 (comment)
The behavior is correct when the total number of lines output so far is less than historySize (default is 9001)
However, once more than historySize lines has been written to the terminal, then if you try to scroll back (even if it is just a few lines) then new output lines will cause terminal to continue to scroll. I think the more reasonable expected behavior should be that terminal should continue to pause scrolling and history can be truncated as needed.