Feature Request: Pause output or scrolling on click (and make it a setting)

[zadjii-msft]

See also #408

[DHowett-MSFT]

This will first require us to implement "pause output on click" ;)

[zadjii-msft]

Oh man I thought we already did that by default. 🥚 🤕

[binarycrusader]

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]

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.

[carlos-zamora]

This will first require us to implement "pause output on click" ;)

Lumping the implementation of that into this issue since making it a setting is probably the least of the work here.

[KonstantinKhabarlak]

For me, it’s important to have a way of actually pausing a process (not just stopping the scroll) for long-running compute-intensive tasks (like ffmpeg encoding) just like it currently works in PowerShell.

[Jaykul]

I agree with binarycrusader, I don't care about pausing the execution, but I desperately want to be able to stop the scrolling so I can

1. scroll back to and check that red error message that just flew by...
2. copy some text output, without waiting for everything to finish

[garyo]

Need this, please. Just a setting for "auto-scroll to end on new output" which I'd turn off. The behavior should be (IMHO) if the scrollbar is at the end and new output appears, keep scrolling to show it. If the scrollbar is not at the end and the above option is off, don't autoscroll -- keep showing the current screen. (The scrollbar thumb will get smaller and higher as more output is produced, that's fine.) Then when the user scrolls back down to the end, it starts autoscrolling again. I know some folks also like "auto-scroll to end on keyboard input"; the two settings often go together. But they should be kept separate; I like auto-scroll on keyboard input (i.e. if I type into the terminal I want to see what I'm typing) but I don't want it to autoscroll my error message off the screen while I'm trying to read it.

[frankseide]

Yes, this is how it should be. I find it interesting that each time something gets rewritten, some of the basics need to be rediscovered.

[DHowett-MSFT]

@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]

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]

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]

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]

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.

[ghost]

🎉This issue was addressed in #6062, which has now been successfully released as Windows Terminal Preview v1.2.2022.0.:tada:

Handy links:

• Release Notes
• Store Download

[garyo]

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; done to repro in a Linux shell.

[iamahumanbeing]

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.