Terminal: 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. :egg: 🤕

[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.

[KhabarlakKonstantin]

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

[michaldobrodenka]

At least to have a feature not to reset scroll on display change (as on Mac)

[ValZapod]

Hello everybody! I do not know all the details about conhost.exe and why did you do this. Pause on click @KhabarlakKonstantin is bad. You cannot stop the kernel right? Why do you think one should stop a process? So we have this in ffmpeg. https://trac.ffmpeg.org/ticket/7318#comment:7
So, mmm... This is bad, okay?

[binarycrusader]

I think many of us agree pausing execution is undesirable, but pausing scrolling seems perfectly safe and a feature that other terminals have.

[ValZapod]

@binarycrusader Indeed! That is what I was thinking about! (Though gnome terminal does not have this, as far as I know.) P.S. Now it has it in Debian 10! And i do not think it is always safe, unfortunately((
Pausing execution is cool but not on click! Maybe alt + click! Really!

[frankseide]

As much as I like the mouse, it would also be great if there was a keyboard version of this. Unfortunately, Ctrl-S does not universally work, e.g. PowerShell or the fish shell. Someone suggested ScrollLock. It would be great to be able to both stop the output and be able to page through with the keyboard.

For reference, the classic xterm allows to stop output with Ctrl-S and then to use Shift-PageUp/Down to page through the output.

[natewaddoups-MSFT]

I love the idea of making the Scroll Lock key _actually do what it says._

For example if reams of logs are flying past, I want to be able to press Scroll Lock, then use pageup/pagedown to review the data (for bonus points, let me use cursor and shift keys to select text, then ctrl-c to copy) and then press Scroll Lock again to return to normal.

[jazzdelightsme]

I like what @natewaddoups-MSFT says, HOWEVER I'd still also like the "pause output on click" because (drum roll, please)... my laptop keyboards do not have a Scroll Lock key.

[michaldobrodenka]

On MAC when you scroll up using mouse, display output is automatically paused

[ffays]

The Scroll Lock key exists since the XT keyboard, and has been precisely designed for this intend of use: to stop scrolling when activated.

So please, the Terminal application must honor the Scroll Lock key state.

[mattleibow]

I think that just scrolling up should pause the scroll. Most windows do this, macOS terminal and the VS IDE output windows. Basically, if I have manually scrolled, then I clearly want to scroll. All I have to do is scroll down to the bottom again and then the auto-scroll can start again.

Click-to-pause is nice, but... sometimes I accidentally click because I bump the trackpad or tap the screen with my nice touchscreen. Let my scroll control the scroll, and my tap just be a focus thing.

Thoughts?

[ValZapod]

@mattleibow Why you cannot scroll AT ALL without pausing EXECUTION! Stop that Microsoft, really! Also I want to be able to disable pause EXECUTION on left click.

[ValZapod]

@mattleibow You can turn off scrolling at all in settings (in PowerShell anyway).

[z0rgy]

@mattleibow I agree that makes sense, since the user is choosing to scroll, give the user control of the scrollbar. There might be an issue in giving back control to the terminal, im not sure how that would happen as the bottom will keep on changing?

[ValZapod]

@z0rgy Let us consider the following. "able to disable pause EXECUTION on left click" Are we all for that? Like me with thumbs up for that to show that to Microsoft. Consider that ffmpeg.exe https://ffmpeg.zeranoe.com/builds/ (ffplay.exe smth) is broken by that. (Music continues playing, while video stops.) And many software which will use kernel async functions or depens on "real time" will be broken by that, etc, etc.

Second. We should look for implementations of auto "/n or /r" scrolling in other software. Connectbot, kde and gnome terminals, main terminal on linux AlT-CTL-F5, maybe some other shells, and made Microsoft to implement the one that looks the best. You can use scroll lock to lock it (and stop execution). You can scroll the linux main terminal with shift + Page Up, but it will not stop getting the output (and thus scrolling fully down). With connectbot it another thing, it just scrolls down but not fully, only so many lines the output really scrolled. With debian gnome terminal it does what we want it to do. It disables auto scroll unless we scroll down and well made it autoscroll again. It does not also pause the execution on scroll lock. So why not just look in implemenatation of that? It is open and we are open, right?
This one is good https://github.com/microsoft/terminal/issues/3679 but it is sh**, obviously.

[z0rgy]

I personally do not like the idea of stopping execution. I would like my application to carry on producing output to stdout.

[ValZapod]

@z0rgy Do you like gnome terminal in Debian? Can you test it? Maybe post a gif, thanks))

[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.

[ValZapod]

The scrollbar thumb will get smaller and higher as more output is produced, that's fine.

Yes! Just like in gnome-terminal! It is perfect there... Sigh.

[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.

[ValZapod]

Oh, MSFT!

scrollback thumb staying in place and getting smaller

This. Please, can you just look how gnome-terminal looks like (in Ubuntu, I prefer Kali linux though)?

[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... 😮

[ValZapod]

by pausing output if the buffer is full

No. They pause not output they pause execution. So, no! Also gnome terminal has unlimited buffer.

[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.

[msftbot[bot]]

:tada: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 https://github.com/microsoft/terminal/issues/980#issuecomment-663924928

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.