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: Preserve scroll position while not "at bottom" #3863

Closed
geordiemhall opened this issue Dec 6, 2019 · 3 comments · Fixed by #6062
Closed

Feature Request: Preserve scroll position while not "at bottom" #3863

geordiemhall opened this issue Dec 6, 2019 · 3 comments · Fixed by #6062
Assignees
Labels
Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Task It's a feature request, but it doesn't really need a major design. Priority-1 A description (P1) 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

@geordiemhall
Copy link

geordiemhall commented Dec 6, 2019

Description of the new feature/enhancement

I tried searching for this but couldn't find any dupes, but please let me know if this is already possible!

It'd be great to (at least have an option to) preserve the terminal scroll position while you aren't scrolled to the bottom.

Eg. If I'm doing a build or something, which is logging out info every second, but then want to scroll up and take a look at an error message I noticed higher up, my view shouldn't be affected by new lines being printed to the terminal. Whereas currently the view jerks around as new stuff is appended to it, making it impossible to actually read any history.

If I then scroll back down "as far as you can go", that should then be a signal to "stick" the scroll with the latest output again.

Could also be nice to have a small button appear somewhere if new lines have been printed while you were scrolled up, which you could click to jump back to the "stuck to the bottom" mode.

Thanks!

@geordiemhall geordiemhall added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Dec 6, 2019
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Dec 6, 2019
@carlos-zamora
Copy link
Member

We don't have a duplicate bug for this, but it'd definitely on our radar. :)

I'll be sure to add it to #2529, since there was a similar request in that PR.

@carlos-zamora carlos-zamora added Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Product-Terminal The new Windows Terminal. and removed Needs-Tag-Fix Doesn't match tag requirements labels Dec 6, 2019
@DHowett-MSFT DHowett-MSFT added Issue-Task It's a feature request, but it doesn't really need a major design. and removed Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Dec 9, 2019
@DHowett-MSFT DHowett-MSFT added this to the Terminal v1.0 milestone Dec 9, 2019
@zadjii-msft zadjii-msft added the Priority-1 A description (P1) label Jan 15, 2020
@PhMajerus
Copy link

This seems like something that would finally put the Scroll Lock key to good use, it should be a toggle available through a tab right-click menu, as well as the Scroll Lock key for faster keyboard use.

Related: Tabs could show some icon when new content has been added to their buffer while they were not visible, like the audio notification icon in Edge. This would make it easy to see some update happened while working in another tab.

@carlos-zamora carlos-zamora self-assigned this May 12, 2020
@ghost ghost added the In-PR This issue has a related PR label Jul 7, 2020
@ghost ghost closed this as completed in #6062 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 removed the In-PR This issue has a related PR label Jul 9, 2020
@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:

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Task It's a feature request, but it doesn't really need a major design. Priority-1 A description (P1) 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.

6 participants