-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Experimental: add support for scrollbar marks #12948
Conversation
…erimental-marks # Conflicts: # src/terminal/adapter/ITermDispatch.hpp # src/terminal/adapter/adaptDispatch.hpp # src/terminal/adapter/termDispatch.hpp
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't reviewed in full - I was just looking at the dispatch code because I wanted to make sure it was going to work with the upcoming architectural changes.
|
#13163) Implements the **FTCS_PROMPT** sequence, `OSC 133 ; A ST`. In this PR, it's just used to set a simple Prompt mark on the current line, in the same way that the iTerm2 sequence works. There's rumination in #11000 on how to implement the rest of the FTCS sequences. This is broken into its own PR at the moment. [Quoth j4james](#12948 (comment)): > That should be just as easy, and I've noticed a couple of other terminals that are doing that, so it's not unprecedented. If we don't have any immediate use for the other options, there shouldn't be any harm in ignoring them initially. > > And the benefit of going with the more widely supported sequence is that we're more likely to benefit from any shells that have this functionality built in. Otherwise they're forced to try and detect the terminal, which is practically impossible for Windows Terminal. Even iTerm2 supports the `OSC 133` sequence, so we'd probably be the only odd one out. This part of the plumbing is super easy, so I thought it would be valuable to add regardless if we get to the whole of FTCS in 1.15. * [x] I work here * [x] Tested manually - in my pwsh `$PROFILE`: ```pwsh function prompt { $loc = $($executionContext.SessionState.Path.CurrentLocation); $out = "PS $loc$('>' * ($nestedPromptLevel + 1)) "; $out += "$([char]27)]9;9;`"$loc`"$([char]07)"; $out += "$([char]27)]133;A;$([char]7)"; # add the FTCS_PROMPT to the... well, end, but you get the point return $out } ``` * See also #11000
When I moved this into ControlCore, I forgot that UserScrollViewport is usually triggered by the scrollbar updating, so it doesn't ask the UI to update. Since this logic is in ControlCore, it's sorta in a weird place where it needs to communicate both up and down: * update the `Terminal`'s viewport position * update the `TermControl`'s scrollbar position Checklist: * [x] Closes a bug bash bug * [x] Missed in #12948 * See also #11000
Update schema with the settings/actions added in #12948 ## PR Checklist * [x] Closes #13404 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated.
Update schema with the settings/actions added in #12948 ## PR Checklist * [x] Closes #13404 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Schema updated. (cherry picked from commit 478c2c3) Service-Card-Id: 83790285 Service-Version: 1.15
🎉 Handy links: |
Link above is now a 404, so: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-15-release/#scroll-marks-experimental (have moved comments re: not being able to make scroll marks to a separate issue linked below). |
Sorry I was using terminal stable, in preview it is ok by default, thank you!
|
Adds support for marks in the scrollbar. These marks can be added in 3
ways:
OSC 1337 ; SetMark
sequenceaddMark
actionexperimental.autoMarkPrompts
per-profilesetting 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, useplace the mark covering at the selection. Otherwise, place the mark
on the cursor row.
color
: a color for the scrollbar mark. This is optional - defaultsto the
foreground
color of the current scheme if omitted.scrollToMark
direction
:["first", "previous", "next", "last"]
clearMark
: Clears marks at the current postition (either theselection if there is one, or the cursor position.
clearAllMarks
: Don't think this needs explanation.Per-profile settings
experimental.autoMarkPrompts
:bool
, defaultfalse
.experimental.showMarksOnScrollbar
:bool
PR Checklist
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, butit seemed like since the only way to see these guys was via the
experimental.showMarksOnScrollbar
setting, you've already brokenyourself into experimental jail, and you know what you're doing.
Things that won't work as expected:
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:
showMarksOnScrollbar: flags(categories)
, so youcan only display errors on the scrollbar
category
flag to theaddMark
actionValidation 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.
Settings blob