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

Hold position in history on scroll up #6324

Closed
tobico opened this issue Jun 3, 2020 · 2 comments
Closed

Hold position in history on scroll up #6324

tobico opened this issue Jun 3, 2020 · 2 comments
Labels
Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.

Comments

@tobico
Copy link

tobico commented Jun 3, 2020

Description of the new feature/enhancement

If I have a running process which is rapidly adding output to the terminal, the displayed text often moves too quickly to read easily.

On many other terminals, if I scroll up to view historical output then the position in history will be held in place as new lines are added at the bottom of the output, causing the viewed to text to become stationary and able to be read. If I then scroll back to the very bottom of the output the terminal will continue automatically scrolling down to display new lines as they're added.

That is, while Windows Terminal does currently remember the position I've scrolled back to, I want that position to correspond to a specific line of text in the output even when new lines are constantly being added, so that it's possible for me to read it clearly.

Proposed technical implementation details (optional)

Without knowing much about the implementation details of Windows Terminal, there are a few ways I imagine this could work:

  1. The scroll position is stored as a count of the total number of lines output since the start of the session. When the window is scrolled to the very bottom, the scroll position is automatically incremented as new lines are displayed, and when the window is scrolled up this autoincrement is skipped.

  2. The scroll position is stored as the number of lines back from the final line the user has scrolled, with 0 being the position for a window which has not been scrolled back at all. When this scroll back position is more than 0 and new lines are added to the output, this position is automatically incremented by the number of lines being added, to keep the output displayed on the screen the same.

  3. The scroll position is stored as an offset from the very earliest line of scroll-back history which is stored. When old history is automatically removed from storage while the window is scrolled up, the scroll offset would be automatically decremented to match the number of lines removed, keeping the output displayed on the screen the same.

@tobico tobico added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Jun 3, 2020
@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 Jun 3, 2020
@zadjii-msft
Copy link
Member

Hey wadda ya know, this is the topic of heated discussion over in #2529, and it's got a draft implementation in #6062. I'm gonna resolve this as a dup of the original issue:

/dup #980

@ghost
Copy link

ghost commented Jun 3, 2020

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost ghost closed this as completed Jun 3, 2020
@ghost ghost added Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. and removed 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 Jun 3, 2020
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Projects
None yet
Development

No branches or pull requests

2 participants