FR: IDE-style marks on scrollbar #2081

@mcpiroman commented on GitHub (Jun 24, 2019):

Technical consideration: Should the scroll bar be implemented as:

ScrollBar as it is now, but with some custom overlay drawings (idk if that's possible)
New control based on uwp primitives (just like the ScrollBar is implemented)
New control based on custom rendering, potentially SwapChainPanel

@mcpiroman commented on GitHub (Jun 24, 2019): Technical consideration: Should the scroll bar be implemented as: 1. `ScrollBar` as it is now, but with some custom overlay drawings (idk if that's possible) 2. New control based on uwp primitives (just like the `ScrollBar` is implemented) 3. New control based on custom rendering, potentially `SwapChainPanel`

claunia commented

@DHowett-MSFT commented on GitHub (Jun 27, 2019):

We've had a "minimap" on our backlog for a while, so this would be a logical extension/step to that. I'm marking this one as backlog. 😄

@DHowett-MSFT commented on GitHub (Jun 27, 2019): We've had a "minimap" on our backlog for a while, so this would be a logical extension/step to that. I'm marking this one as backlog. :smile:

claunia commented

@zadjii-msft commented on GitHub (Jul 2, 2019):

I'm no XAML expert, but I'd think it'd be possible to put some sort of transparent control over the bounds of the scrollbar, and draw rectangles into that area. We'd have to be careful not to accept any mouse input in that region, but that seems possible to me.

Now here's a question - if we're not doing this "minimap" style, and instead we're just putting little ticks there, how do we determine a tick should be placed? The terminal doesn't know when one command starts or ends, so the shell would have to communicate that to us somehow. Alternatively, we could try a keybinding that the user presses to manually add a tick - though that might not be the best either. Additionally, how would a tick get removed? Could the user click on them to change colors/delete? If so, I'd probably prefer the VS style ticks.

(I'm adding the extensibility tag, since this seems like a good extension case)

@zadjii-msft commented on GitHub (Jul 2, 2019): I'm no XAML expert, but I'd think it'd be possible to put some sort of transparent control over the bounds of the scrollbar, and draw rectangles into that area. We'd have to be careful not to accept any mouse input in that region, but that seems possible to me. Now here's a question - if we're not doing this "minimap" style, and instead we're just putting little ticks there, how do we determine a tick should be placed? The terminal doesn't know when one command starts or ends, so the shell would have to communicate that to us somehow. Alternatively, we could try a keybinding that the user presses to manually add a tick - though that might not be the best either. Additionally, how would a tick get removed? Could the user click on them to change colors/delete? If so, I'd probably prefer the VS style ticks. (I'm adding the extensibility tag, since this seems like a good extension case)

claunia commented

@mcpiroman commented on GitHub (Jul 3, 2019):

I'm no XAML expert, but I'd think it'd be possible to put some sort of transparent control over the bounds of the scrollbar, and draw rectangles into that area.

Yes, but only if it was to draw above the scrollbar. So the marks couldn't go below the thumb or be otherwise integrated into scrollbar. That said, it might be enough.

if we're not doing this "minimap" style

Minimap is another story. This feature just offers quick orientation glance with the benefit that it doesn't require any additional space (assuming that scorllbar is visible). Sublime-style minimap will still be useful.

The terminal doesn't know when one command starts or ends, so the shell would have to communicate that to us somehow.

That's the hard part. It could be done by modifing cmd and powershell to emit some vt sequence or api call at prompt/command start/end, but this wouldn't do for linux shells. Alternatively we can detect the prompt (by emited text, read request, checking if the child-most process is bash or not). This could work for linux shells, but I don't know if wsl would share the process tree information. The problem here is with scripts that use @echo off and potentially with built-in commands like cd.

Alternatively, we could try a keybinding that the user presses to manually add a tick

That seems more like bookmark and yes, I'd like that too.

@mcpiroman commented on GitHub (Jul 3, 2019): > I'm no XAML expert, but I'd think it'd be possible to put some sort of transparent control over the bounds of the scrollbar, and draw rectangles into that area. Yes, but only if it was to draw above the scrollbar. So the marks couldn't go below the thumb or be otherwise integrated into scrollbar. That said, it might be enough. > if we're not doing this "minimap" style Minimap is another story. This feature just offers quick orientation glance with the benefit that it doesn't require any additional space (assuming that scorllbar is visible). Sublime-style minimap will still be useful. > The terminal doesn't know when one command starts or ends, so the shell would have to communicate that to us somehow. That's the hard part. It could be done by modifing cmd and powershell to emit some vt sequence or api call at prompt/command start/end, but this wouldn't do for linux shells. Alternatively we can detect the prompt (by emited text, read request, checking if the child-most process is bash or not). This could work for linux shells, but I don't know if wsl would share the process tree information. The problem here is with scripts that use `@echo off` and potentially with built-in commands like `cd`. > Alternatively, we could try a keybinding that the user presses to manually add a tick That seems more like bookmark and yes, I'd like that too.

claunia commented

@lzybkr commented on GitHub (Dec 5, 2019):

I don't care about the scrollbar UI, but I'd love the ability to easily jump between commands with a key binding and considered adding something to PSReadLine when it was Windows only using the Win32 console apis. That plan quietly died when switching to vt sequences for portability.

It looks like mintty implements a vt sequence for this already: https://github.com/mintty/mintty/wiki/CtrlSeqs#scroll-markers

@lzybkr commented on GitHub (Dec 5, 2019): I don't care about the scrollbar UI, but I'd love the ability to easily jump between commands with a key binding and considered adding something to PSReadLine when it was Windows only using the Win32 console apis. That plan quietly died when switching to vt sequences for portability. It looks like mintty implements a vt sequence for this already: https://github.com/mintty/mintty/wiki/CtrlSeqs#scroll-markers

claunia commented

@jkuebart commented on GitHub (Mar 11, 2020):

I would like to strongly support @lzybkr's suggestion and point out that macOS's Terminal.app has a very simple, but effective implementation: When pressing Enter, the current line is automatically »marked«. Visually, this is indicated by little brackets on the side of the line – but that's not the interesting/useful part: subsequently, it's possible to navigate between these lines using Command-↑ and Command-↓, among other things. The marked lines scroll into view, making it very convenient to navigate the terminal's back buffer.

Another really nice feature is Command-Shift-A which selects the text up to the most recently marked line: for example, one can simply type »ls« enter, Command-Shift-A Command-C, which selects the output of the command and copies it to the clipboard.

Proposed technical implementation details (optional)

I have no idea how it could be implemented in practice, but it doesn't feel like a very big feature. I think that the visual feedback is secondary, just marking a line automatically after hitting enter already covers 99% of use cases.

The most important keyboard shortcuts are »up« and »down« to scroll the back buffer between the marks. The second most important shortcut is to select from the current position to the most recent mark, but even that could be implemented as a second step.

Terminal.app has more features such as marking manually, bookmarks &c which I have never used, so seems comparatively unimportant.

@jkuebart commented on GitHub (Mar 11, 2020): I would like to strongly support @lzybkr's [suggestion](https://github.com/microsoft/terminal/issues/1527#issuecomment-562313307) and point out that macOS's Terminal.app has a very simple, but effective implementation: When pressing `Enter`, the current line is automatically »marked«. Visually, this is indicated by little brackets on the side of the line – but that's not the interesting/useful part: subsequently, it's possible to navigate between these lines using Command-↑ and Command-↓, among other things. The marked lines scroll into view, making it very convenient to navigate the terminal's back buffer. Another really nice feature is Command-Shift-A which selects the text up to the most recently marked line: for example, one can simply type »ls« enter, Command-Shift-A Command-C, which selects the output of the command and copies it to the clipboard. # Proposed technical implementation details (optional) I have no idea how it could be implemented in practice, but it doesn't feel like a very big feature. I think that the visual feedback is secondary, just marking a line automatically after hitting enter already covers 99% of use cases. The most important keyboard shortcuts are »up« and »down« to scroll the back buffer between the marks. The second most important shortcut is to select from the current position to the most recent mark, but even that could be implemented as a second step. Terminal.app has more features such as marking manually, bookmarks &c which I have never used, so seems comparatively unimportant.

claunia commented

@zadjii-msft commented on GitHub (Jul 6, 2020):

From @ralph-snart in #6801:

On macOS, its built-in Terminal app provides a really handy way to navigate up and down through all the prompts and also user-defined locations in the terminal window's visible history, in the form of "Marks" and "Bookmarks", complete with their own keyboard shortcuts and various menu items.

This would be a very convenient feature to port over to and adapt in Windows Terminal as well.

For specifics on macOS Terminal's "Marks" and "Bookmarks" features, please see:

support.apple.com/en-ca/guide/terminal/trml135fbc26/mac

howtogeek.com/256548/how-to-use-marks-in-os-xs-terminal-for-easier-navigation

scriptingosx.com/2017/03/terminal-the-marks-the-spot

@zadjii-msft commented on GitHub (Jul 6, 2020): From @ralph-snart in #6801: > > On macOS, its built-in Terminal app provides a really handy way to navigate up and down through all the prompts and also user-defined locations in the terminal window's visible history, in the form of "Marks" and "Bookmarks", complete with their own keyboard shortcuts and various menu items. > > This would be a very convenient feature to port over to and adapt in Windows Terminal as well. > > For specifics on macOS Terminal's "Marks" and "Bookmarks" features, please see: > > * [support.apple.com/en-ca/guide/terminal/trml135fbc26/mac](https://support.apple.com/en-ca/guide/terminal/trml135fbc26/mac) > * [howtogeek.com/256548/how-to-use-marks-in-os-xs-terminal-for-easier-navigation](https://www.howtogeek.com/256548/how-to-use-marks-in-os-xs-terminal-for-easier-navigation/) > * [scriptingosx.com/2017/03/terminal-the-marks-the-spot](https://scriptingosx.com/2017/03/terminal-the-marks-the-spot/)

claunia commented

@AltitudeApps commented on GitHub (Aug 31, 2020):

Hi, I happened across this issue when looking for something else, but I thought I'd comment.

I would like to suggest that you consider separate vertical gutters, either beside the scrollbar, or as suggested rendered directly on the existing scrollbar.

The minimap is interesting, too. I leave both the scrollbar and minimap enabled when using editors in VSCode, and if I woke up three years from now to see a similar arrangement in Terminal, I would not be surprised.

However, the information presented as little indicators on the scrollbar can get really crowded, sometimes to the point of making it completely useless.

So, I'm going to suggest the same thing I'd like to see in VSCode: the ability to specify n, where n>1, "micro-map" scrollbar annotation columns, which can be either composed side by side, or have a subset configured to contribute annotations to the same column. (In the case where the annotations are expected to be sparse). In other words, they would be semi-transparent and rendered within the same rectangle.

Many times when the annotations are dense, even though the scrollbar indicator control is partly transparent, the blending of the colors makes it so that items are no longer instantly recognizable when that particular annotation moves from the free area of the scrollbar to a position underneath the scroll indicator.

@AltitudeApps commented on GitHub (Aug 31, 2020): Hi, I happened across this issue when looking for something else, but I thought I'd comment. I would like to suggest that you consider separate vertical gutters, either beside the scrollbar, or as suggested rendered directly on the existing scrollbar. The minimap is interesting, too. I leave both the scrollbar and minimap enabled when using editors in VSCode, and if I woke up three years from now to see a similar arrangement in Terminal, I would not be surprised. However, the information presented as little indicators on the scrollbar can get *really* crowded, sometimes to the point of making it completely useless. So, I'm going to suggest the same thing I'd like to see in VSCode: the ability to specify n, where n>1, "micro-map" scrollbar annotation columns, which can be either composed side by side, or have a subset configured to contribute annotations to the same column. (In the case where the annotations are expected to be sparse). In other words, they would be semi-transparent and rendered within the same rectangle. Many times when the annotations are dense, even though the scrollbar indicator control is partly transparent, the blending of the colors makes it so that items are no longer instantly recognizable when that particular annotation moves from the free area of the scrollbar to a position underneath the scroll indicator.

claunia commented

@zadjii-msft commented on GitHub (Mar 22, 2022):

xlink: #6232

I mean like conceptually, super easy. dev/migrie/fhl/scroll-marks-prototype

Formalizing this is a little tricker of course. I really like the little marks, even though I thought I might hate it. iTerm2 and Terminal.app do these a little differently, so we'd want to make sure we do them in a relatively unified way.

This implementation doesn't at all account for the various prompt markup sequences either. I kinda went ham on just this current approach. I'd want to make sure both will work.

I may also reach out to xterm.js in case @Tyriar has any other ideas for things to add to the marks.

@zadjii-msft commented on GitHub (Mar 22, 2022): xlink: #6232 ![fhl-scroll-marks-prototype-001](https://user-images.githubusercontent.com/18356694/159571075-7265524d-e1cd-468b-9af4-e0b50c392c63.gif) I mean like conceptually, super easy. `dev/migrie/fhl/scroll-marks-prototype` Formalizing this is a little tricker of course. I really like the little marks, even though I thought I might hate it. iTerm2 and Terminal.app do these a little differently, so we'd want to make sure we do them in a relatively unified way. This implementation doesn't at _all_ account for the various prompt markup sequences either. I kinda went ham on just this current approach. I'd want to make sure both will work. I may also reach out to xterm.js in case @Tyriar has any other ideas for things to add to the marks.

claunia commented

@Tyriar commented on GitHub (Mar 22, 2022):

@meganrogge and I have been working on the decorations feature in vscode for the last couple of months:

We're still polishing and adding to it but the "overview ruler" (same name as monaco) currently includes:

Success/skipped/error commands
Find matches
The focus cursor (when finding or navigating commands)

@Tyriar commented on GitHub (Mar 22, 2022): @meganrogge and I have been working on the decorations feature in vscode for the last couple of months: ![image](https://user-images.githubusercontent.com/2193314/159579604-64566b48-f103-4704-9c4c-0ab73095f1f7.png) We're still polishing and adding to it but the "overview ruler" (same name as monaco) currently includes: - Success/skipped/error commands - Find matches - The focus cursor (when finding or navigating commands)

claunia commented

@Tyriar commented on GitHub (Mar 22, 2022):

I would like to strongly support @lzybkr's https://github.com/microsoft/terminal/issues/1527#issuecomment-562313307 and point out that macOS's Terminal.app has a very simple, but effective implementation: When pressing Enter, the current line is automatically »marked«.

Also FWIW this is the baseline behavior in VS Code for identifying commands, but you can enable experimental shell integration which gives more accurate/richer results.

@Tyriar commented on GitHub (Mar 22, 2022): > I would like to strongly support @lzybkr's https://github.com/microsoft/terminal/issues/1527#issuecomment-562313307 and point out that macOS's Terminal.app has a very simple, but effective implementation: When pressing Enter, the current line is automatically »marked«. Also FWIW this is the baseline behavior in VS Code for identifying commands, but you can enable experimental shell integration which gives more accurate/richer results.

claunia commented

@jkuebart commented on GitHub (Mar 23, 2022):

This implementation doesn't at all account for the various prompt markup sequences either.

Do you mean the code is interpreting the output or styling to recognise places to be marked and skipped back to?

I think a better approach than trying to second-guess prompts is to use lines on which Enter is pressed. Apart from the fact that most prompts can be customised, people are going to be using all kinds of interactive applications: gdb, lldb, fdisk -e, disklabel and so on and so on. They're also going to be logging into remote systems running who-knows-what OSs. So I don't think there will ever be a way to tell wether any given line of output is a prompt.

Saying that, of course it makes perfect sense for there to be command sequences that allow applications to control the behaviour explicitly.

@jkuebart commented on GitHub (Mar 23, 2022): > This implementation doesn't at all account for the various prompt markup sequences either. Do you mean the code is interpreting the output or styling to recognise places to be marked and skipped back to? I think a better approach than trying to second-guess prompts is to use lines on which Enter is pressed. Apart from the fact that most prompts can be customised, people are going to be using all kinds of interactive applications: `gdb`, `lldb`, `fdisk -e`, `disklabel` and so on and so on. They're also going to be logging into remote systems running who-knows-what OSs. So I don't think there will ever be a way to tell wether any given line of output is a prompt. Saying that, of course it makes perfect sense for there to be command sequences that allow applications to control the behaviour explicitly.

claunia commented

@zadjii-msft commented on GitHub (Mar 23, 2022):

This implementation doesn't at all account for the various prompt markup sequences either.

Do you mean the code is interpreting the output or styling to recognise places to be marked and skipped back to?

Ah, no, I meant the prompt sequences used by Final Term / iTerm2 (et al). There's some docs on the iTerm2 docs, under "Shell Integration/FinalTerm".

My prototype yesterday was just using the iTerm2 OSC 1337 ; SetMark ST sequence in my prompt, so the prompt would explicitly tell the Terminal where the prompt started.

use lines on which Enter is pressed

Added that in 29478a6.

the "overview ruler" (same name as monaco) currently includes....

Ah. So y'all got three different sets of "marks" to display. Okay, that's not a bad idea. That does complicate the design a tad bit, but that can be sorted out in the spec review.

So basically there are

marks (either from FinalTerm/VsCode prompt sequences, iTerm2 SetMark, {maybe we want to add our own sequence here?}, or marks added manually via actions)
find results
where the cursor / current selection is (maybe lower priority?)
- maybe correct me if I'm wrong, but seems like we don't need to necessarily track which command is being viewed, we could just move the viewport up/down to the prev/next mark, and that's the one that's viewed.

Right now, what I've got is absolutely hackathon quality code. I'm personally also of the shared opinion from before:

the information presented as little indicators on the scrollbar can get really crowded, sometimes to the point of making it completely useless

so maybe there's a design where you can either have all the marks in the scrollbar as little pips (like VS, Monaco), or as whole lines (like JetBrains IDEs), or as separate columns (to the right of the scrollbar?)

@zadjii-msft commented on GitHub (Mar 23, 2022): > > This implementation doesn't at all account for the various prompt markup sequences either. > > Do you mean the code is interpreting the output or styling to recognise places to be marked and skipped back to? Ah, no, I meant the prompt sequences used by Final Term / iTerm2 (et al). There's some docs on [the iTerm2 docs, under "Shell Integration/FinalTerm"](https://iterm2.com/documentation-escape-codes.html). My prototype yesterday was just using the iTerm2 `OSC 1337 ; SetMark ST` sequence in my prompt, so the prompt would explicitly tell the Terminal where the prompt started. > use lines on which Enter is pressed Added that in 29478a6. <hr> > the "overview ruler" (same name as monaco) currently includes.... Ah. So y'all got three different sets of "marks" to display. Okay, that's not a bad idea. That does complicate the design a tad bit, but that can be sorted out in the spec review. So basically there are * marks (either from FinalTerm/VsCode prompt sequences, iTerm2 SetMark, {maybe we want to add our own sequence here?}, or marks added manually via actions) * find results * where the cursor / current selection is (maybe lower priority?) - maybe correct me if I'm wrong, but seems like we don't need to necessarily track which command is being viewed, we could just move the viewport up/down to the prev/next mark, and _that's the one that's viewed_. Right now, what I've got is absolutely hackathon quality code. I'm personally also of the shared opinion from before: > the information presented as little indicators on the scrollbar can get really crowded, sometimes to the point of making it completely useless so maybe there's a design where you can either have all the marks in the scrollbar as little pips (like VS, Monaco), or as whole lines (like JetBrains IDEs), or as separate columns (to the right of the scrollbar?)

claunia commented