Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
zadjii-msft opened this issue May 24, 2019 · 36 comments · Fixed by #6062
Closed

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

zadjii-msft opened this issue May 24, 2019 · 36 comments · Fixed by #6062
Assignees
Labels
Area-Settings Issues related to settings and customizability, for console or terminal Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone

Comments

@zadjii-msft
Copy link
Member

See also #408

@zadjii-msft zadjii-msft added Help Wanted We encourage anyone to jump in on these. Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Area-Settings Issues related to settings and customizability, for console or terminal Product-Terminal The new Windows Terminal. Issue-Task It's a feature request, but it doesn't really need a major design. labels May 24, 2019
@zadjii-msft zadjii-msft added this to the Terminal v1.0 milestone May 24, 2019
@ghost ghost added the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label May 24, 2019
@DHowett-MSFT
Copy link
Contributor

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

@zadjii-msft
Copy link
Member Author

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

@binarycrusader
Copy link
Member

binarycrusader commented 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 DHowett-MSFT added Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. and removed Issue-Task It's a feature request, but it doesn't really need a major design. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels May 28, 2019
@DHowett-MSFT
Copy link
Contributor

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 DHowett-MSFT changed the title Feature Request: Add a setting to disable pausing output on click Feature Request: Add a setting to disable pausing output or scrolling on click May 28, 2019
@carlos-zamora
Copy link
Member

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 carlos-zamora self-assigned this Jun 5, 2019
@carlos-zamora carlos-zamora changed the title Feature Request: Add a setting to disable pausing output or scrolling on click Feature Request: Pause output or scrolling on click (and make it a setting) Jun 5, 2019
@KonstantinKhabarlak
Copy link

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
Copy link
Contributor

Jaykul commented 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

@ghost ghost added In-PR This issue has a related PR and removed In-PR This issue has a related PR labels Aug 24, 2019
@carlos-zamora carlos-zamora removed the Help Wanted We encourage anyone to jump in on these. label Aug 24, 2019
@garyo
Copy link

garyo commented 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.

@frankseide
Copy link

frankseide commented Mar 31, 2020 via email

@DHowett-MSFT
Copy link
Contributor

DHowett-MSFT commented 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
Copy link
Contributor

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
Copy link

tovine commented 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
Copy link

kived commented 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
Copy link

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 pushed a commit that referenced this issue Jul 7, 2020
## Summary of the Pull Request

This proposes a change to how Terminal will scroll in response to newly
generated output. The Terminal will scroll upon receiving new output if
the viewport is at the bottom of the scroll history and no selection is
active.

This spec also explores the possibility of making this response
configurable with a `snapOnOutput` profile setting. It also discusses
the possibility of adding a scroll lock keybinding action.

## PR Checklist
* [X] Spec for #980
@ghost ghost closed this as completed in #6062 Jul 9, 2020
@ghost ghost removed the In-PR This issue has a related PR label Jul 9, 2020
ghost pushed a commit that referenced this issue Jul 9, 2020
## Summary of the Pull Request
Updates the Terminal's scroll response to new output. The Terminal will not automatically scroll if...
- a selection is active, or
- the viewport is at the bottom of the scroll history

## References
#2529 - Spec
#3863 - Implementation

## PR Checklist
* [X] Closes #980
* [X] Closes #3863
* [ ] Tests added/passed
* [ ] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments
Updates the `_scrollOffset` value properly in TerminalCore when the cursor moves. We calculate a new `_scrollOffset` based on if we are circling the buffer and how far below the mutable bottom is.

We specifically check for if a selection is active and if the viewport is at the bottom, then use that as a condition for deciding if we should update `_scrollOffset` to the new calculated value or 0 (the bottom of the scroll history).

## Validation Steps Performed
Manual testing. Though I should add automated tests.
- [X] new output
- [X] new output when circling
- [X] new output when circling and viewport is at the top
@ghost ghost added the Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. label Jul 9, 2020
@ghost
Copy link

ghost commented Jul 22, 2020

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

Handy links:

@garyo
Copy link

garyo commented 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.

@iamahumanbeing
Copy link

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.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Settings Issues related to settings and customizability, for console or terminal Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.