Scroll to previous/next prompt #6232
Comments
ghost
added
Needs-Triage
carlos-zamora
added
Area-Interaction
|
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. |
|
There was some minor discussion about this in #1527. Yanking triage to throw this on the backlog. |
DHowett
removed
the
Needs-Triage
zadjii-msft
added
Area-Input
|
Visual Studio Code has an implementation here: code.visualstudio.com/updates/v1_22#_command-tracking |
|
It seems to only guess. Why no integration instead? Such as a VT seq extension? |
|
I believe they do actually use a VT sequence. Originally it was the Final Term |
|
xlink: #1527. I'm messing around with these for hack week. |
carlos-zamora
added
A11yMAS
|
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...
Bonus points:
|
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
added
Needs-Tag-Fix
|
🎉This issue was addressed in #12948, which has now been successfully released as Handy links: |
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:
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.
The text was updated successfully, but these errors were encountered: