forked from microsoft/terminal
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
WIP: Expose current TextAttributes from the underlying console API.
This is not a polished PR that is ready to merge; it demonstrates a direction for which I need to get buy-off from the team before pursuing further. I'm currently working on implementing the XTPUSHSGR/XTPOPSGR control sequences (WIP PR [here](microsoft#1978), which requires saving a [stack of] text attributes, and not just the legacy attributes, but full RGB colors, etc. My first instinct was to implement the "business logic" (the stack) in the `AdaptDispatch` layer, but that will require getting the [full] text attributes from the underlying console API. This is not a *terribly* "invasive" change, but it is exposing new stuff at a layer boundary. Put another way, this means pound-including the "../buffer/out/TextAttribute.hpp" header in a few places outside of "buffer/out", and is that okay, or does that header need to be kept private and isolated? So there are a few ways this could go: 1. You folks might say "ugh, no!", and: 1. I could push (haha) the business logic of pushing and popping text attributes down another layer (so `AdaptDispatch` just forwards on the [PushGraphicsRendition](https://github.com/microsoft/terminal/blob/0af275b9cb68da14f38f05b2cdcbb35da99cb17c/src/terminal/adapter/adaptDispatchGraphics.cpp#L452) call to the lower layer, OR 2. You suggest a different, cleaner way of exposing the text attributes. OR 2. Maybe you think this general direction is fine, but maybe you have some particular requests that I do certain things differently (I totally understand being picky about stuff that cuts across API layers). What do you think?
- Loading branch information
1 parent
eae920e
commit afa6722
Showing
7 changed files
with
46 additions
and
15 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters