-
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
Changes from all commits
687b6e6
48d8a3e
018bbf8
d203dcb
0998431
c1ed74a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -315,6 +315,21 @@ CATCH_RETURN() | |
} | ||
|
||
_api.selectionSpans = til::point_span_subspan_within_rect(info.selectionSpans, dr); | ||
|
||
const 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 commentThe reason will be displayed to describe this comment to others. Learn more. Copying from You can test that this by setting a breakpoint into There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 Should PaintBufferLineHelper be reading them out of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I made the call to read them out of |
||
misc->selectionColor = newSelectionColor; | ||
// Select a black or white foreground based on the perceptual lightness of the background. | ||
misc->selectionForeground = ColorFix::GetLuminosity(newSelectionColor) < 0.5f ? 0xffffffff : 0xff000000; | ||
|
||
// We copied the selection colors into _p during StartPaint, which happened just before PrepareRenderInfo | ||
// This keeps their generations in sync. | ||
auto pm = _p.s.write()->misc.write(); | ||
pm->selectionColor = misc->selectionColor; | ||
pm->selectionForeground = misc->selectionForeground; | ||
} | ||
} | ||
|
||
return S_OK; | ||
|
@@ -502,7 +517,7 @@ try | |
// Apply the highlighting colors to the highlighted cells | ||
RETURN_IF_FAILED(_drawHighlighted(_api.searchHighlights, y, x, columnEnd, highlightFg, highlightBg)); | ||
RETURN_IF_FAILED(_drawHighlighted(_api.searchHighlightFocused, y, x, columnEnd, highlightFocusFg, highlightFocusBg)); | ||
RETURN_IF_FAILED(_drawHighlighted(_api.selectionSpans, y, x, columnEnd, _api.s->misc->selectionForeground, _api.s->misc->selectionColor)); | ||
RETURN_IF_FAILED(_drawHighlighted(_api.selectionSpans, y, x, columnEnd, _p.s->misc->selectionForeground, _p.s->misc->selectionColor)); | ||
|
||
_api.lastPaintBufferLineCoord = { x, y }; | ||
return S_OK; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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 commentThe reason will be displayed to describe this comment to others. Learn more. this is xterm's name for selection color |
||
{ | ||
std::vector<DWORD> colors; | ||
success = _GetOscSetColor(string, colors); | ||
|
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.
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".
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.