-
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
Allow OSC 17 to set the selection background color #17742
Conversation
src/renderer/atlas/AtlasEngine.cpp
Outdated
@@ -315,6 +315,15 @@ CATCH_RETURN() | |||
} | |||
|
|||
_api.selectionSpans = til::point_span_subspan_within_rect(info.selectionSpans, dr); | |||
|
|||
u32 newSelectionColor{ static_cast<COLORREF>(info.selectionBackground) | 0xff000000 }; |
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.
@lhecker please check me on this - I don't think there's another place for us to propagate this...
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.
Seems good to me!
@@ -804,6 +804,7 @@ bool OutputStateMachineEngine::ActionOscDispatch(const size_t parameter, const s | |||
case OscActionCodes::SetForegroundColor: | |||
case OscActionCodes::SetBackgroundColor: | |||
case OscActionCodes::SetCursorColor: | |||
case OscActionCodes::SetHighlightColor: |
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.
this is xterm's name for selection color
static constexpr size_t SELECTION_BACKGROUND = 266; | ||
static constexpr size_t TABLE_SIZE = 267; |
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.
If there's a chance we may one day support a selection foreground color like Xterm does, it may be a good idea to reserve that slot now, so we've always got our foreground and background colors paired in the same order.
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.
Actually, I love that. That ship may have sailed for the cursor color, however... as i have always wanted to add cursor foreground.
Since we didn't have palette report support before (unreleased) 1.221, is there still time to make changes in our reserved color indices?
Footnotes
-
under the assumption that we want them stable now that people can back up and restore them :) ↩
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.
That ship may have sailed for the cursor color, however... as i have always wanted to add cursor foreground.
Cursor color is a bit of a special case, because it can be thought of as both foreground and background depending on the style. When it's the block style, you think of the cursor color as a background attribute, and when it's the underline or bar style it's more like a foreground attribute.
But if you consider the way cursors were originally implemented, it makes the most sense as a foreground attribute, because the block cursor was really just implemented as a reverse attribute toggle. So if your default text is white on black, and your cursor color is say green, then an underline cursor is going to be green on black, and a block cursor is just green on black reversed. In both case the black background is retained, and the foreground white is replaced with green.
That said, if you wanted to introduce a second cursor color, referring to the two as foreground and background is going to be confusing no matter which way you look at it, and maybe it would be easiest to refer to the second color and something generic like "secondary cursor color".
Since we didn't have palette report support before (unreleased) 1.22, is there still time to make changes in our reserved color indices?
I don't think we want to mess with the default text and frame indices, because even though we couldn't query them, we've already been telling people they can set the colors at those specific positions. The cursor color is probably less of an issue, because I don't think we've publicaly mentioned its value anywhere. But as I explained above, I don't think we necessarily should be changing that anywav - just reserve a slot for a "secondary cursor color" if you think we're going to need that.
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.
Oh, that makes way more sense. Thanks for explaining.
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.
Do you not still want to reserve a spot for a SECONDARY_CURSOR_COLOR
before the new selection color entries, or have you decided we aren't likely to need that?
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.
Eh, I was going to leave it. But you're right, I might as well.
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.
Leonard's position is more (paraphrased by me) "If these aren't a committed public API, we should be able to renumber them at our leisure later." I have not fully digested how I feel about Terminal Preview and DECCTR.
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.
Yeah, I'm OK with that too.
The base branch was changed.
This removes the AtlasEngine-specific `SetSelectionBackground` completely. Selection background is now propagated in PrepareRenderInfo (for now).
be022ad
to
d203dcb
Compare
u32 newSelectionColor{ static_cast<COLORREF>(info.selectionBackground) | 0xff000000 }; | ||
if (_api.s->misc->selectionColor != newSelectionColor) | ||
{ | ||
auto misc = _api.s.write()->misc.write(); |
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.
Copying from _api.s
to _p.s
happens in StartPaint()
. Similar to AtlasEngine::PaintCursor
you need to update both structs simultaneously to keep their generation count in sync.
You can test that this by setting a breakpoint into AtlasEngine::_handleSettingsUpdate
. Then and emit an OSC 17. If done correctly, AtlasEngine::_handleSettingsUpdate
should not get called.
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.
Oh no, this is interesting. It didn't cause a problem because I didn't understand your architecture.
I put the selection colors on _api
, and I read them out of _api
. I didn't even know (remember?) that they would also be on _p
.
Should PaintBufferLineHelper be reading them out of _p
instead?
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 made the call to read them out of _p
, because that's the RenderingPayload.
This pull request adds support for setting and querying the selection
color with
OSC 17
.To make this possible, I had to move selection color down into the color
table where it always belonged. This lets us get rid of the special
SetSelectionColor
method from the surface of AtlasEngine, and reunitesselection colors with the rest of the special colors.