FR: IDE-style marks on scrollbar

[mcpiroman]

Summary of the new feature/enhancement

Introduce marks and indicators on scrollbar:

1. Command seperators / prompt positions

• Program runs and you want to see how long the current output is. You can look at scrollbar and see where is the last command marker.
• You run gcc --help=common that prints ~900 lines of output, and you know the interesting switch is somewhere in the middle. By viewing the command's input line position you can easily navigate to that location.
• You are running well-known batch script and want to know current state. You can look at scrollbar to count number of commands that has already run or even notice that second command has abnormally big output.
• Just helps with navigation over previous command.

2. Selection span

• Not as usefull but nice looking.

3. Colors of text / lines

• You run some build script that prints errors in red and warnings in yellow. You can leave it running and them just glance at scrollbar to see if there are any issues (and locate them).
• You run some port scanning script (like this) that prints successful connections in green and unsuccessful in red. Much like above.
• You run git status that prints everything in green, but then look at scrollbar and see that one, sneeky, unstaged, red line.

Example looks:

Visual Studio	IDEA InteliJ

Proposed technical implementation details (optional)

• This should be controlled by per profile settings
• When there is one line, say red, surrounded by great number of green lines, that red dot or strip should have some minimum size to ensure it's visible.
• When only part of the line is colored it should be show the same way as if whole line was colored
• What if there are two colors on same line?

[DHowett-MSFT]

Clever feature request, and one we haven't seen before. Thanks!

[mcpiroman]

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

[DHowett-MSFT]

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. 😄

[zadjii-msft]

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)

[mcpiroman]

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.

[lzybkr]

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

[jkuebart]

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.

[zadjii-msft]

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

[AltitudeApps]

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.

[zadjii-msft]

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.

[Tyriar]

@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]

I would like to strongly support @lzybkr's #1527 (comment) 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.

[jkuebart]

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.

[zadjii-msft]

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?)

[Tyriar]

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.

We probably would have gone with something simpler but this is aligning closely to VS Code's editor which shows scm decorations on left, find results/highlights in middle and errors/warnings on the right. So the user is already familiar with the concept. While more complex, it also ends up much less noisy that using "full" horizontal lines (see image below).

marks (either from FinalTerm/VsCode prompt sequences, iTerm2 SetMark, {maybe we want to add our own sequence here?}, or marks added manually via actions)

Be warned if you go this route, it's quite difficult to get this reliably because of conpty doesn't guarantee the marks are in the correct position. Additionally the lack of an alt buffer can lead to odd behavior.

I think passthrough #1173 is what we need to make this simpler? If you could just allow some sequences to be "rendered" at the correct cell this would make our lives so much easier.

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.

We decided not to show the cursor since it's always at the bottom, instead it's currently used for the current find match and for command navigation:

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?)

Initially we showed a full line for each command and it was useless imo as it quickly ended up looking like this:

The problem is exacerbated by the fact that VS Code's terminal is normally quite short vertically.

[zadjii-msft]

Be warned if you go this route, it's quite difficult to get this reliably because of conpty doesn't guarantee the marks are in the correct position. Additionally the lack of an alt buffer can lead to odd behavior.

Hah, I have a fairly clever solution for that right now. Whenever we see one of these sequences in conpty, we'll immediately end the current frame and start buffering a new one, and then just adding the sequence directly to the conpty output. That results in the sequence being sent to the terminal with the terminal in the full state you'd expect for when the sequence was emitted. I actually used that to support the alt buffer, which all this work is forked off of 😋

You're right though, passthrough would make this simpler.

Initially we showed a full line for each command and it was useless imo as it quickly ended up looking like this:

{image}

HO BOY yea good point. Maybe we just stick with pips. I'm all for aligning with our other first party partners ☺️

[Tyriar]

Whenever we see one of these sequences in conpty

Are we meant to have this in older versions of conpty? The sequences definitely often print in the wrong spot. Do you just do this for just OSC 7 and 133 because we're using OSC 633 currently. It would happen for all OSC sequences imo.

[zadjii-msft]

Are we meant to have this in older versions of conpty?

Ah no, that work is still in PR right now (#12561). It's not an amazing solution. I'd have to go through and manually flush the frame on sequences we think that conhost isn't going to handle. I think there's a bit more discussion in #8698.

[Tyriar]

@zadjii-msft cool, well alt buffer support will be great when we eventually get it as well.

[ghost]

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

Handy links:

• Release Notes
• Store Download