starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

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

New Issue
Closed
opened 2026-01-30 22:22:05 +00:00 by claunia · 27 comments
claunia commented 2026-01-30 22:22:05 +00:00
Owner
Copy Link

Originally created by @zadjii-msft on GitHub (May 24, 2019).

Originally assigned to: @carlos-zamora on GitHub.

See also #408

Originally created by @zadjii-msft on GitHub (May 24, 2019). Originally assigned to: @carlos-zamora on GitHub. See also #408
claunia commented 2026-01-30 22:22:07 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 24, 2019):

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

@DHowett-MSFT commented on GitHub (May 24, 2019): This will first require us to _implement_ "pause output on click" ;)
claunia commented 2026-01-30 22:22:07 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 24, 2019):

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

@zadjii-msft commented on GitHub (May 24, 2019): Oh man I thought we already did that by default. :egg: 🤕
claunia commented 2026-01-30 22:22:07 +00:00
Author
Owner
Copy Link

@binarycrusader commented on GitHub (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).

@binarycrusader commented on GitHub (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).
claunia commented 2026-01-30 22:22:08 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (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.

@DHowett-MSFT commented on GitHub (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.
claunia commented 2026-01-30 22:22:08 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Jun 5, 2019):

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.

@carlos-zamora commented on GitHub (Jun 5, 2019): > 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.
claunia commented 2026-01-30 22:22:09 +00:00
Author
Owner
Copy Link

@KonstantinKhabarlak commented on GitHub (Jun 28, 2019):

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.

@KonstantinKhabarlak commented on GitHub (Jun 28, 2019): 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.
claunia commented 2026-01-30 22:22:09 +00:00
Author
Owner
Copy Link

@Jaykul commented on GitHub (Aug 5, 2019):

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
@Jaykul commented on GitHub (Aug 5, 2019): 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
claunia commented 2026-01-30 22:22:10 +00:00
Author
Owner
Copy Link

@michaldobrodenka commented on GitHub (Aug 29, 2019):

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

@michaldobrodenka commented on GitHub (Aug 29, 2019): At least to have a feature not to reset scroll on display change (as on Mac)
claunia commented 2026-01-30 22:22:10 +00:00
Author
Owner
Copy Link

@binarycrusader commented on GitHub (Sep 27, 2019):

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

@binarycrusader commented on GitHub (Sep 27, 2019): I think many of us agree pausing *execution* is undesirable, but pausing *scrolling* seems perfectly safe and a feature that other terminals have.
claunia commented 2026-01-30 22:22:11 +00:00
Author
Owner
Copy Link

@frankseide commented on GitHub (Oct 25, 2019):

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.

@frankseide commented on GitHub (Oct 25, 2019): 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.
claunia commented 2026-01-30 22:22:11 +00:00
Author
Owner
Copy Link

@natewaddoups-MSFT commented on GitHub (Oct 31, 2019):

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.

@natewaddoups-MSFT commented on GitHub (Oct 31, 2019): 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.
claunia commented 2026-01-30 22:22:11 +00:00
Author
Owner
Copy Link

@jazzdelightsme commented on GitHub (Oct 31, 2019):

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.

@jazzdelightsme commented on GitHub (Oct 31, 2019): 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.
claunia commented 2026-01-30 22:22:12 +00:00
Author
Owner
Copy Link

@michaldobrodenka commented on GitHub (Nov 1, 2019):

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

@michaldobrodenka commented on GitHub (Nov 1, 2019): On MAC when you scroll up using mouse, display output is automatically paused
claunia commented 2026-01-30 22:22:12 +00:00
Author
Owner
Copy Link

@ffays commented on GitHub (Nov 18, 2019):

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.

@ffays commented on GitHub (Nov 18, 2019): 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.
claunia commented 2026-01-30 22:22:12 +00:00
Author
Owner
Copy Link

@mattleibow commented on GitHub (Nov 24, 2019):

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?

@mattleibow commented on GitHub (Nov 24, 2019): 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?
claunia commented 2026-01-30 22:22:13 +00:00
Author
Owner
Copy Link

@z0rgy commented on GitHub (Nov 24, 2019):

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

@z0rgy commented on GitHub (Nov 24, 2019): @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?
claunia commented 2026-01-30 22:22:13 +00:00
Author
Owner
Copy Link

@z0rgy commented on GitHub (Dec 7, 2019):

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

@z0rgy commented on GitHub (Dec 7, 2019): I personally do not like the idea of stopping execution. I would like my application to carry on producing output to stdout.
claunia commented 2026-01-30 22:22:13 +00:00
Author
Owner
Copy Link

@garyo commented on GitHub (Mar 31, 2020):

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.

@garyo commented on GitHub (Mar 31, 2020): 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.
claunia commented 2026-01-30 22:22:13 +00:00
Author
Owner
Copy Link

@frankseide commented on GitHub (Mar 31, 2020):

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.

@frankseide commented on GitHub (Mar 31, 2020): 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.
claunia commented 2026-01-30 22:22:14 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Mar 31, 2020):

@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 commented on GitHub (Mar 31, 2020): @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".
claunia commented 2026-01-30 22:22:14 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (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.

@DHowett-MSFT commented on GitHub (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.
claunia commented 2026-01-30 22:22:15 +00:00
Author
Owner
Copy Link

@tovine commented on GitHub (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... 😮

@tovine commented on GitHub (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... 😮
claunia commented 2026-01-30 22:22:15 +00:00
Author
Owner
Copy Link

@kived commented on GitHub (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.

@kived commented on GitHub (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.
claunia commented 2026-01-30 22:22:15 +00:00
Author
Owner
Copy Link

@frankseide commented on GitHub (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.

@frankseide commented on GitHub (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.
claunia commented 2026-01-30 22:22:15 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 22, 2020):

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

Handy links:

@ghost commented on GitHub (Jul 22, 2020): :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](https://github.com/microsoft/terminal/releases/tag/v1.2.2022.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
claunia commented 2026-01-30 22:22:15 +00:00
Author
Owner
Copy Link

@garyo commented on GitHub (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; done to repro in a Linux shell.

@garyo commented on GitHub (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; done` to repro in a Linux shell.
claunia commented 2026-01-30 22:22:16 +00:00
Author
Owner
Copy Link

@iamahumanbeing commented on GitHub (Aug 2, 2020):

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.

@iamahumanbeing commented on GitHub (Aug 2, 2020): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Settings Area-TerminalControl Issue-Feature Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#1312
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?