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.

Sign up for GitHub

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

Jump to bottom

Scroll to previous/next prompt #6232

Closed
carlos-zamora opened this issue May 28, 2020 · 8 comments · Fixed by #12948
Closed

Scroll to previous/next prompt #6232

carlos-zamora opened this issue May 28, 2020 · 8 comments · Fixed by #12948
Labels
A11yMAS Accessibility tracking Area-Accessibility Issues related to accessibility Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Disability-Mobility Accessibility tracking InclusionBacklog Accessibility tracking InclusionBacklog-Windows TerminalWin32 Accessibility tracking InclusionCommitted-202206 Accessibility tracking Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Needs-Tag-Fix Doesn't match tag requirements Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone
Terminal v1.15

Comments

@carlos-zamora
Copy link
Member

Another suggestion: how hard would it be to account for navigation in the output buffer by command?

For example, lets say you have the following terminal output:

> pwd
/some/path

> dir
// lots of output

> whoami
some-user

I would like to be able to skip past the output of a command and move to the input prompt of the next one. For example, if my cursor were at the bottom, pressing some keystroke would move me to the second last line. Pressing it again moves me to the input prompt where I typed dir, allowing me to easily skip past the many lines of output. This could let me then go down to review the output of the dir command at my leisure, especially useful in the situation where it scrolls on for many lines.

Originally posted by @Neurrone in #5804 (comment)

Description of the new feature/enhancement

In macOS' terminal, pressing cmd+up/down scrolls the terminal to the previous/next prompt. As mentioned above, this would be a useful way to navigate the buffer.

Proposed technical implementation details (optional)

I genuinely don't know how this is done. Maybe you could cache the position where user input occurred? Then navigate through those? Even then, when using a text editor like vim, Terminal should scroll up to the previous prompt, instead of the previous line.
@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 May 28, 2020
@carlos-zamora carlos-zamora added Area-Interaction Interacting with the vintage console window (as opposed to driving via API or hooks) Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal. labels May 28, 2020
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 28, 2020
@carlos-zamora carlos-zamora added this to the Terminal Backlog milestone May 28, 2020
@carlos-zamora carlos-zamora mentioned this issue May 28, 2020
Merged
1 task
@j4james
Copy link
Collaborator

j4james commented May 28, 2020 •
edited
Loading

I believe this is achieved with a set of OSC escape sequences that "mark up" the prompt and command output. The original concept came from Final Term, which had also sorts interactive integration with command output (you can read a blog post on some of the ideas here). iTerm2 copied some of those features and as well as adding their own extensions (see here).

Edit: I should also mention that Mintty has its own way of doing this, but it's horrible abuse of the mode system, so I wouldn't want to recommend that approach.

@Neurrone Neurrone mentioned this issue May 28, 2020
Closed
@DHowett
Copy link
Member

DHowett commented May 28, 2020

There was some minor discussion about this in #1527. Yanking triage to throw this on the backlog.

@DHowett DHowett removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label May 28, 2020
@zadjii-msft zadjii-msft added Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) and removed Area-Interaction Interacting with the vintage console window (as opposed to driving via API or hooks) labels Jul 7, 2020
@KalleOlaviNiemitalo KalleOlaviNiemitalo mentioned this issue Apr 19, 2021
Open
@j4james j4james mentioned this issue Oct 21, 2021
Open
@zadjii-msft zadjii-msft modified the milestones: Terminal Backlog, Backlog Jan 4, 2022
@j4james j4james mentioned this issue Mar 5, 2022
Closed
@carlocardella
Copy link
Member

carlocardella commented Mar 5, 2022 •
edited
Loading

Visual Studio Code has an implementation here:

code.visualstudio.com/updates/v1_22#_command-tracking
scrollToPreviousCommand

@christianparpart
Copy link

It seems to only guess. Why no integration instead? Such as a VT seq extension?

@j4james
Copy link
Collaborator

j4james commented Mar 5, 2022

I believe they do actually use a VT sequence. Originally it was the Final Term OSC 133 sequence, which quite a few other terminals are using now, but they recently decided to switch to their own proprietary sequence for some reason. 🤷‍♂️

See here:
https://github.com/microsoft/vscode/blob/39cc1e1c42b2e53e83b1846c2857ca194848cc1d/src/vs/workbench/contrib/terminal/browser/xterm/shellIntegrationAddon.ts#L50-L52

@zadjii-msft zadjii-msft mentioned this issue Mar 22, 2022
Closed
@zadjii-msft
Copy link
Member

xlink: #1527. I'm messing around with these for hack week.

@zadjii-msft zadjii-msft mentioned this issue Mar 28, 2022
Open
37 tasks
@zadjii-msft zadjii-msft modified the milestones: Backlog, Terminal v1.15 Mar 28, 2022
@zadjii-msft zadjii-msft mentioned this issue Apr 20, 2022
Merged
2 tasks
@ghost ghost added the In-PR This issue has a related PR label Apr 20, 2022
@carlos-zamora carlos-zamora added A11yMAS Accessibility tracking InclusionBacklog Accessibility tracking InclusionBacklog-Windows TerminalWin32 Accessibility tracking Disability-Mobility Accessibility tracking InclusionCommitted-202206 Accessibility tracking labels Jun 7, 2022
@carlos-zamora
Copy link
Member Author

Considering this feature as a positive impact for accessibility scenarios. Thus, tagging it up appropriately for the inclusion backlog.

Currently, scrolling between prompts is an annoying process. You need to repeatedly scroll up/down by line/page and scan the terminal contents to get to where you want to be. Generally speaking, users think of the terminal as chunks of command output, so jumping from one prompt to the other is the most common scenario for scrolling. This can be particularly annoying for some users with disabilities...

  • low mobility users:
    • repeatedly pressing the scroll button is very relevant here.
  • low vision users:
    • every scroll operation requires the user to scan the new visible text, extrapolate context, and determine if they need to scroll more. By reducing the operation to "scroll to previous prompt", we're reducing the extra work necessary here. This is especially useful for users with screen readers.

Bonus points:

  • we could probably have the screen reader emit semantic info on the FTCS sequences "command succeeded/failed" and expose that to the scroll markers. Users may then be able to filter through markers more easily.

@carlos-zamora carlos-zamora added the Area-Accessibility Issues related to accessibility label Jun 7, 2022
zadjii-msft added a commit that referenced this issue Jun 9, 2022
@zadjii-msft
Experimental: add support for scrollbar marks (#12948)
799b5d4 
Adds support for marks in the scrollbar. These marks can be added in 3
ways:
* Via the iterm2 `OSC 1337 ; SetMark` sequence
* Via the `addMark` action
* Automatically when the `experimental.autoMarkPrompts` per-profile
  setting is enabled.

#11000 has more tracking for the big-picture for this feature, as well
as additional follow-ups. This set of functionality seemed complete
enough to send a review for now. That issue describes these how I wish
these actions to look in the fullness of time.  This is simply the v0.1
from the hackathon last month.

#### Actions

* `addMark`: add a mark to the buffer. If there's a selection, use
   place the mark covering at the selection. Otherwise, place the mark
   on the cursor row. 
  - `color`: a color for the scrollbar mark. This is optional - defaults
    to the `foreground` color of the current scheme if omitted.
* `scrollToMark`
  - `direction`: `["first", "previous", "next", "last"]`
* `clearMark`: Clears marks at the current postition (either the
  selection if there is one, or the cursor position.
* `clearAllMarks`: Don't think this needs explanation.

#### Per-profile settings

* `experimental.autoMarkPrompts`: `bool`, default `false`.
* `experimental.showMarksOnScrollbar`: `bool` 

## PR Checklist
* [x] Closes #1527
* [x] Closes #6232

## Detailed Description of the Pull Request / Additional comments

This is basically hackathon code. It's experimental! That's okay! We'll
figure the rest of the design in post.

Theoretically, I should make these actions `experimental.` as well, but
it seemed like since the only way to see these guys was via the
`experimental.showMarksOnScrollbar` setting, you've already broken
yourself into experimental jail, and you know what you're doing.

Things that won't work as expected:
* resizing, ESPECIALLY reflowing
* Clearing the buffer with ED sequences / Clear Buffer

I could theoretically add velocity around this in the `TermControl`
layer. Always prevent marks from being visible, ignore all the actions.
Marks could still be set by VT and automark, but they'd be useless.

Next up priorities:
* Making this work with the FinalTerm sequences
* properly speccing
* adding support for `showMarksOnScrollbar: flags(categories)`, so you
  can only display errors on the scrollbar
* adding the `category` flag to the `addMark` action

## Validation Steps Performed

I like using it quite a bit. The marks can get noisy if you have them
emitted on every prompt and the buffer has 9000 lines. But that's the
beautiful thing, the actions work even if the marks aren't visible, so
you can still scroll between prompts. 

<details>
<summary>Settings blob</summary>

```jsonc
// actions
        { "keys": "ctrl+up", "command": { "action": "scrollToMark", "direction": "previous" }, "name": "Previous mark" },
        { "keys": "ctrl+down", "command": { "action": "scrollToMark", "direction": "next" }, "name": "Next mark" },
        { "keys": "ctrl+pgup", "command": { "action": "scrollToMark", "direction": "first" }, "name": "First mark" },
        { "keys": "ctrl+pgdn", "command": { "action": "scrollToMark", "direction": "last" }, "name": "Last mark" },
        { "command": { "action": "addMark" } },
        { "command": { "action": "addMark", "color": "#ff00ff" } },
        { "command": { "action": "addMark", "color": "#0000ff" } },
        { "command": { "action": "clearAllMarks" } },

// profiles.defaults
        "experimental.autoMarkPrompts": true,
        "experimental.showMarksOnScrollbar": true,
```

</details>
@ghost ghost added Needs-Tag-Fix Doesn't match tag requirements Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Jun 9, 2022
@ghost
Copy link

ghost commented Jul 6, 2022

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

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A11yMAS Accessibility tracking Area-Accessibility Issues related to accessibility Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Disability-Mobility Accessibility tracking InclusionBacklog Accessibility tracking InclusionBacklog-Windows TerminalWin32 Accessibility tracking InclusionCommitted-202206 Accessibility tracking Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Needs-Tag-Fix Doesn't match tag requirements 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
Milestone
Terminal v1.15
Development

Successfully merging a pull request may close this issue.

Experimental: add support for scrollbar marks microsoft/terminal
6 participants
@christianparpart @DHowett @j4james @carlocardella @carlos-zamora @zadjii-msft