2019-05-03 00:29:04 +02:00
|
|
|
// Copyright (c) Microsoft Corporation.
|
|
|
|
|
// Licensed under the MIT license.
|
|
|
|
|
|
|
|
|
|
#include "precomp.h"
|
|
|
|
|
#include "WexTestClass.h"
|
|
|
|
|
#include "../../inc/consoletaeftemplates.hpp"
|
|
|
|
|
|
|
|
|
|
#include "../TextColor.h"
|
|
|
|
|
|
|
|
|
|
using namespace WEX::Common;
|
|
|
|
|
using namespace WEX::Logging;
|
|
|
|
|
using namespace WEX::TestExecution;
|
|
|
|
|
|
|
|
|
|
class TextColorTests
|
|
|
|
|
{
|
|
|
|
|
TEST_CLASS(TextColorTests);
|
|
|
|
|
|
|
|
|
|
TEST_CLASS_SETUP(ClassSetup);
|
|
|
|
|
|
|
|
|
|
TEST_METHOD(TestDefaultColor);
|
|
|
|
|
TEST_METHOD(TestDarkIndexColor);
|
|
|
|
|
TEST_METHOD(TestBrightIndexColor);
|
|
|
|
|
TEST_METHOD(TestRgbColor);
|
|
|
|
|
TEST_METHOD(TestChangeColor);
|
|
|
|
|
|
|
|
|
|
static const int COLOR_TABLE_SIZE = 16;
|
|
|
|
|
COLORREF _colorTable[COLOR_TABLE_SIZE];
|
|
|
|
|
COLORREF _defaultFg = RGB(1, 2, 3);
|
|
|
|
|
COLORREF _defaultBg = RGB(4, 5, 6);
|
|
|
|
|
std::basic_string_view<COLORREF> _GetTableView();
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
bool TextColorTests::ClassSetup()
|
|
|
|
|
{
|
|
|
|
|
_colorTable[0] = RGB(12, 12, 12); // Black
|
|
|
|
|
_colorTable[1] = RGB(0, 55, 218); // Dark Blue
|
|
|
|
|
_colorTable[2] = RGB(19, 161, 14); // Dark Green
|
|
|
|
|
_colorTable[3] = RGB(58, 150, 221); // Dark Cyan
|
|
|
|
|
_colorTable[4] = RGB(197, 15, 31); // Dark Red
|
|
|
|
|
_colorTable[5] = RGB(136, 23, 152); // Dark Magenta
|
|
|
|
|
_colorTable[6] = RGB(193, 156, 0); // Dark Yellow
|
|
|
|
|
_colorTable[7] = RGB(204, 204, 204); // Dark White
|
|
|
|
|
_colorTable[8] = RGB(118, 118, 118); // Bright Black
|
|
|
|
|
_colorTable[9] = RGB(59, 120, 255); // Bright Blue
|
|
|
|
|
_colorTable[10] = RGB(22, 198, 12); // Bright Green
|
|
|
|
|
_colorTable[11] = RGB(97, 214, 214); // Bright Cyan
|
|
|
|
|
_colorTable[12] = RGB(231, 72, 86); // Bright Red
|
|
|
|
|
_colorTable[13] = RGB(180, 0, 158); // Bright Magenta
|
|
|
|
|
_colorTable[14] = RGB(249, 241, 165); // Bright Yellow
|
|
|
|
|
_colorTable[15] = RGB(242, 242, 242); // White
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
std::basic_string_view<COLORREF> TextColorTests::_GetTableView()
|
|
|
|
|
{
|
|
|
|
|
return std::basic_string_view<COLORREF>(&_colorTable[0], COLOR_TABLE_SIZE);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void TextColorTests::TestDefaultColor()
|
|
|
|
|
{
|
|
|
|
|
TextColor defaultColor;
|
|
|
|
|
|
|
|
|
|
VERIFY_IS_TRUE(defaultColor.IsDefault());
|
|
|
|
|
VERIFY_IS_FALSE(defaultColor.IsLegacy());
|
|
|
|
|
VERIFY_IS_FALSE(defaultColor.IsRgb());
|
|
|
|
|
|
|
|
|
|
auto view = _GetTableView();
|
|
|
|
|
|
|
|
|
|
auto color = defaultColor.GetColor(view, _defaultFg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(_defaultFg, color);
|
|
|
|
|
|
|
|
|
|
color = defaultColor.GetColor(view, _defaultFg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(_defaultFg, color);
|
|
|
|
|
|
|
|
|
|
color = defaultColor.GetColor(view, _defaultBg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(_defaultBg, color);
|
|
|
|
|
|
|
|
|
|
color = defaultColor.GetColor(view, _defaultBg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(_defaultBg, color);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void TextColorTests::TestDarkIndexColor()
|
|
|
|
|
{
|
Fix SGR indexed colors to distinguish Indexed256 color (and more) (#5834)
This PR introduces a new `ColorType` to allow us to distinguish between
`SGR` indexed colors from the 16 color table, the lower half of which
can be brightened, and the ISO/ITU indexed colors from the 256 color
table, which have a fixed brightness. Retaining the distinction between
these two types will enable us to forward the correct `SGR` sequences to
conpty when addressing issue #2661.
The other benefit of retaining the color index (which we didn't
previously do for ISO/ITU colors) is that it ensures that the colors are
updated correctly when the color scheme is changed.
## References
* This is another step towards fixing the conpty narrowing bugs in issue
#2661.
* This is technically a fix for issue #5384, but that won't be apparent
until #2661 is complete.
## PR Checklist
* [x] Closes #1223
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
The first part of this PR was the introduction of a new `ColorType` in
the `TextColor` class. Instead of just the one `IsIndex` type, there is
now an `IsIndex16` and an `IsIndex256`. `IsIndex16` covers the eight
original ANSI colors set with `SGR 3x` and `SGR 4x`, as well as the
brighter aixterm variants set with `SGR 9x` and `SGR 10x`. `IsIndex256`
covers the 256 ISO/ITU indexed colors set with `SGR 38;5` and `SGR
48;5`.
There are two reasons for this distinction. The first is that the ANSI
colors have the potential to be brightened by the `SGR 1` bold
attribute, while the ISO/ITO color do not. The second reason is that
when forwarding an attributes through conpty, we want to try and
preserve the original SGR sequence that generated each color (to the
extent that that is possible). By having the two separate types, we can
map the `IsIndex16` colors back to ANSI/aixterm values, and `IsIndex256`
to the ISO/ITU sequences.
In addition to the VT colors, we also have to deal with the legacy
colors set by the Windows console APIs, but we don't really need a
separate type for those. It seemed most appropriate to me to store them
as `IsIndex256` colors, since it doesn't make sense to have them
brightened by the `SGR 1` attribute (which is what would happen if they
were stored as `IsIndex16`). If a console app wanted a bright color it
would have selected one, so we shouldn't be messing with that choice.
The second part of the PR was the unification of the two color tables.
Originally we had a 16 color table for the legacy colors, and a separate
table for the 256 ISO/ITU colors. These have now been merged into one,
so color table lookups no longer need to decide which of the two tables
they should be referencing. I've also updated all the methods that took
a color table as a parameter to use a `basic_string_view` instead of
separate pointer and length variables, which I think makes them a lot
easier and safer to work with.
With this new architecture in place, I could now update the
`AdaptDispatch` SGR implementation to store the ISO/ITU indexed colors
as `IsIndex256` values, where before they were mapped to RGB values
(which prevented them reflecting any color scheme changes). I could also
update the `TerminalDispatch` implementation to differentiate between
the two index types, so that the `SGR 1` brightening would only be
applied to the ANSI colors.
I've also done a bit of code refactoring to try and minimise any direct
access to the color tables, getting rid of a lot of places that were
copying tables with `memmove` operations. I'm hoping this will make it
easier for us to update the code in the future if we want to reorder the
table entries (which is likely a requirement for unifying the
`AdaptDispatch` and `TerminalDispatch` implementations).
## Validation Steps Performed
For testing, I've just updated the existing unit tests to account for
the API changes. The `TextColorTests` required an extra parameter
specifying the index type when setting an index. And the `AdapterTest`
and `ScreenBufferTests` required the use of the new `SetIndexedXXX`
methods in order to be explicit about the index type, instead of relying
on the `TextAttribute` constructor and the old `SetForeground` and
`SetBackground` methods which didn't have a way to differentiate index
types.
I've manually tested the various console APIs
(`SetConsoleTextAttribute`, `ReadConsoleOutputAttribute`, and
`ReadConsoleOutput`), to make sure they are still setting and reading
the attributes as well as they used to. And I've tested the
`SetConsoleScreenBufferInfoEx` and `GetConsoleScreenBufferInfoEx` APIs
to make sure they can read and write the color table correctly. I've
also tested the color table in the properties dialog, made sure it was
saved and restored from the registry correctly, and similarly saved and
restored from a shortcut link.
Note that there are still a bunch of issues with the color table APIs,
but no new problems have been introduced by the changes in this PR, as
far as I could tell.
I've also done a bunch of manual tests of `OSC 4` to make sure it's
updating all the colors correctly (at least in conhost), and confirmed
that the test case in issue #1223 now works as expected.
2020-05-28 00:34:45 +02:00
|
|
|
TextColor indexColor((BYTE)(7), false);
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
|
VERIFY_IS_FALSE(indexColor.IsDefault());
|
|
|
|
|
VERIFY_IS_TRUE(indexColor.IsLegacy());
|
|
|
|
|
VERIFY_IS_FALSE(indexColor.IsRgb());
|
|
|
|
|
|
|
|
|
|
auto view = _GetTableView();
|
|
|
|
|
|
|
|
|
|
auto color = indexColor.GetColor(view, _defaultFg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[7], color);
|
|
|
|
|
|
|
|
|
|
color = indexColor.GetColor(view, _defaultFg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[15], color);
|
|
|
|
|
|
|
|
|
|
color = indexColor.GetColor(view, _defaultBg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[7], color);
|
|
|
|
|
|
|
|
|
|
color = indexColor.GetColor(view, _defaultBg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[15], color);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void TextColorTests::TestBrightIndexColor()
|
|
|
|
|
{
|
Fix SGR indexed colors to distinguish Indexed256 color (and more) (#5834)
This PR introduces a new `ColorType` to allow us to distinguish between
`SGR` indexed colors from the 16 color table, the lower half of which
can be brightened, and the ISO/ITU indexed colors from the 256 color
table, which have a fixed brightness. Retaining the distinction between
these two types will enable us to forward the correct `SGR` sequences to
conpty when addressing issue #2661.
The other benefit of retaining the color index (which we didn't
previously do for ISO/ITU colors) is that it ensures that the colors are
updated correctly when the color scheme is changed.
## References
* This is another step towards fixing the conpty narrowing bugs in issue
#2661.
* This is technically a fix for issue #5384, but that won't be apparent
until #2661 is complete.
## PR Checklist
* [x] Closes #1223
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
The first part of this PR was the introduction of a new `ColorType` in
the `TextColor` class. Instead of just the one `IsIndex` type, there is
now an `IsIndex16` and an `IsIndex256`. `IsIndex16` covers the eight
original ANSI colors set with `SGR 3x` and `SGR 4x`, as well as the
brighter aixterm variants set with `SGR 9x` and `SGR 10x`. `IsIndex256`
covers the 256 ISO/ITU indexed colors set with `SGR 38;5` and `SGR
48;5`.
There are two reasons for this distinction. The first is that the ANSI
colors have the potential to be brightened by the `SGR 1` bold
attribute, while the ISO/ITO color do not. The second reason is that
when forwarding an attributes through conpty, we want to try and
preserve the original SGR sequence that generated each color (to the
extent that that is possible). By having the two separate types, we can
map the `IsIndex16` colors back to ANSI/aixterm values, and `IsIndex256`
to the ISO/ITU sequences.
In addition to the VT colors, we also have to deal with the legacy
colors set by the Windows console APIs, but we don't really need a
separate type for those. It seemed most appropriate to me to store them
as `IsIndex256` colors, since it doesn't make sense to have them
brightened by the `SGR 1` attribute (which is what would happen if they
were stored as `IsIndex16`). If a console app wanted a bright color it
would have selected one, so we shouldn't be messing with that choice.
The second part of the PR was the unification of the two color tables.
Originally we had a 16 color table for the legacy colors, and a separate
table for the 256 ISO/ITU colors. These have now been merged into one,
so color table lookups no longer need to decide which of the two tables
they should be referencing. I've also updated all the methods that took
a color table as a parameter to use a `basic_string_view` instead of
separate pointer and length variables, which I think makes them a lot
easier and safer to work with.
With this new architecture in place, I could now update the
`AdaptDispatch` SGR implementation to store the ISO/ITU indexed colors
as `IsIndex256` values, where before they were mapped to RGB values
(which prevented them reflecting any color scheme changes). I could also
update the `TerminalDispatch` implementation to differentiate between
the two index types, so that the `SGR 1` brightening would only be
applied to the ANSI colors.
I've also done a bit of code refactoring to try and minimise any direct
access to the color tables, getting rid of a lot of places that were
copying tables with `memmove` operations. I'm hoping this will make it
easier for us to update the code in the future if we want to reorder the
table entries (which is likely a requirement for unifying the
`AdaptDispatch` and `TerminalDispatch` implementations).
## Validation Steps Performed
For testing, I've just updated the existing unit tests to account for
the API changes. The `TextColorTests` required an extra parameter
specifying the index type when setting an index. And the `AdapterTest`
and `ScreenBufferTests` required the use of the new `SetIndexedXXX`
methods in order to be explicit about the index type, instead of relying
on the `TextAttribute` constructor and the old `SetForeground` and
`SetBackground` methods which didn't have a way to differentiate index
types.
I've manually tested the various console APIs
(`SetConsoleTextAttribute`, `ReadConsoleOutputAttribute`, and
`ReadConsoleOutput`), to make sure they are still setting and reading
the attributes as well as they used to. And I've tested the
`SetConsoleScreenBufferInfoEx` and `GetConsoleScreenBufferInfoEx` APIs
to make sure they can read and write the color table correctly. I've
also tested the color table in the properties dialog, made sure it was
saved and restored from the registry correctly, and similarly saved and
restored from a shortcut link.
Note that there are still a bunch of issues with the color table APIs,
but no new problems have been introduced by the changes in this PR, as
far as I could tell.
I've also done a bunch of manual tests of `OSC 4` to make sure it's
updating all the colors correctly (at least in conhost), and confirmed
that the test case in issue #1223 now works as expected.
2020-05-28 00:34:45 +02:00
|
|
|
TextColor indexColor((BYTE)(15), false);
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
|
VERIFY_IS_FALSE(indexColor.IsDefault());
|
|
|
|
|
VERIFY_IS_TRUE(indexColor.IsLegacy());
|
|
|
|
|
VERIFY_IS_FALSE(indexColor.IsRgb());
|
|
|
|
|
|
|
|
|
|
auto view = _GetTableView();
|
|
|
|
|
|
|
|
|
|
auto color = indexColor.GetColor(view, _defaultFg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[15], color);
|
|
|
|
|
|
|
|
|
|
color = indexColor.GetColor(view, _defaultFg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[15], color);
|
|
|
|
|
|
|
|
|
|
color = indexColor.GetColor(view, _defaultBg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[15], color);
|
|
|
|
|
|
|
|
|
|
color = indexColor.GetColor(view, _defaultBg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[15], color);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void TextColorTests::TestRgbColor()
|
|
|
|
|
{
|
|
|
|
|
COLORREF myColor = RGB(7, 8, 9);
|
|
|
|
|
TextColor rgbColor(myColor);
|
|
|
|
|
|
|
|
|
|
VERIFY_IS_FALSE(rgbColor.IsDefault());
|
|
|
|
|
VERIFY_IS_FALSE(rgbColor.IsLegacy());
|
|
|
|
|
VERIFY_IS_TRUE(rgbColor.IsRgb());
|
|
|
|
|
|
|
|
|
|
auto view = _GetTableView();
|
|
|
|
|
|
|
|
|
|
auto color = rgbColor.GetColor(view, _defaultFg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(myColor, color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultFg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(myColor, color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultBg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(myColor, color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultBg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(myColor, color);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void TextColorTests::TestChangeColor()
|
|
|
|
|
{
|
|
|
|
|
COLORREF myColor = RGB(7, 8, 9);
|
|
|
|
|
TextColor rgbColor(myColor);
|
|
|
|
|
|
|
|
|
|
VERIFY_IS_FALSE(rgbColor.IsDefault());
|
|
|
|
|
VERIFY_IS_FALSE(rgbColor.IsLegacy());
|
|
|
|
|
VERIFY_IS_TRUE(rgbColor.IsRgb());
|
|
|
|
|
|
|
|
|
|
auto view = _GetTableView();
|
|
|
|
|
|
|
|
|
|
auto color = rgbColor.GetColor(view, _defaultFg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(myColor, color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultFg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(myColor, color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultBg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(myColor, color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultBg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(myColor, color);
|
|
|
|
|
|
|
|
|
|
rgbColor.SetDefault();
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultFg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(_defaultFg, color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultFg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(_defaultFg, color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultBg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(_defaultBg, color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultBg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(_defaultBg, color);
|
|
|
|
|
|
Fix SGR indexed colors to distinguish Indexed256 color (and more) (#5834)
This PR introduces a new `ColorType` to allow us to distinguish between
`SGR` indexed colors from the 16 color table, the lower half of which
can be brightened, and the ISO/ITU indexed colors from the 256 color
table, which have a fixed brightness. Retaining the distinction between
these two types will enable us to forward the correct `SGR` sequences to
conpty when addressing issue #2661.
The other benefit of retaining the color index (which we didn't
previously do for ISO/ITU colors) is that it ensures that the colors are
updated correctly when the color scheme is changed.
## References
* This is another step towards fixing the conpty narrowing bugs in issue
#2661.
* This is technically a fix for issue #5384, but that won't be apparent
until #2661 is complete.
## PR Checklist
* [x] Closes #1223
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
The first part of this PR was the introduction of a new `ColorType` in
the `TextColor` class. Instead of just the one `IsIndex` type, there is
now an `IsIndex16` and an `IsIndex256`. `IsIndex16` covers the eight
original ANSI colors set with `SGR 3x` and `SGR 4x`, as well as the
brighter aixterm variants set with `SGR 9x` and `SGR 10x`. `IsIndex256`
covers the 256 ISO/ITU indexed colors set with `SGR 38;5` and `SGR
48;5`.
There are two reasons for this distinction. The first is that the ANSI
colors have the potential to be brightened by the `SGR 1` bold
attribute, while the ISO/ITO color do not. The second reason is that
when forwarding an attributes through conpty, we want to try and
preserve the original SGR sequence that generated each color (to the
extent that that is possible). By having the two separate types, we can
map the `IsIndex16` colors back to ANSI/aixterm values, and `IsIndex256`
to the ISO/ITU sequences.
In addition to the VT colors, we also have to deal with the legacy
colors set by the Windows console APIs, but we don't really need a
separate type for those. It seemed most appropriate to me to store them
as `IsIndex256` colors, since it doesn't make sense to have them
brightened by the `SGR 1` attribute (which is what would happen if they
were stored as `IsIndex16`). If a console app wanted a bright color it
would have selected one, so we shouldn't be messing with that choice.
The second part of the PR was the unification of the two color tables.
Originally we had a 16 color table for the legacy colors, and a separate
table for the 256 ISO/ITU colors. These have now been merged into one,
so color table lookups no longer need to decide which of the two tables
they should be referencing. I've also updated all the methods that took
a color table as a parameter to use a `basic_string_view` instead of
separate pointer and length variables, which I think makes them a lot
easier and safer to work with.
With this new architecture in place, I could now update the
`AdaptDispatch` SGR implementation to store the ISO/ITU indexed colors
as `IsIndex256` values, where before they were mapped to RGB values
(which prevented them reflecting any color scheme changes). I could also
update the `TerminalDispatch` implementation to differentiate between
the two index types, so that the `SGR 1` brightening would only be
applied to the ANSI colors.
I've also done a bit of code refactoring to try and minimise any direct
access to the color tables, getting rid of a lot of places that were
copying tables with `memmove` operations. I'm hoping this will make it
easier for us to update the code in the future if we want to reorder the
table entries (which is likely a requirement for unifying the
`AdaptDispatch` and `TerminalDispatch` implementations).
## Validation Steps Performed
For testing, I've just updated the existing unit tests to account for
the API changes. The `TextColorTests` required an extra parameter
specifying the index type when setting an index. And the `AdapterTest`
and `ScreenBufferTests` required the use of the new `SetIndexedXXX`
methods in order to be explicit about the index type, instead of relying
on the `TextAttribute` constructor and the old `SetForeground` and
`SetBackground` methods which didn't have a way to differentiate index
types.
I've manually tested the various console APIs
(`SetConsoleTextAttribute`, `ReadConsoleOutputAttribute`, and
`ReadConsoleOutput`), to make sure they are still setting and reading
the attributes as well as they used to. And I've tested the
`SetConsoleScreenBufferInfoEx` and `GetConsoleScreenBufferInfoEx` APIs
to make sure they can read and write the color table correctly. I've
also tested the color table in the properties dialog, made sure it was
saved and restored from the registry correctly, and similarly saved and
restored from a shortcut link.
Note that there are still a bunch of issues with the color table APIs,
but no new problems have been introduced by the changes in this PR, as
far as I could tell.
I've also done a bunch of manual tests of `OSC 4` to make sure it's
updating all the colors correctly (at least in conhost), and confirmed
that the test case in issue #1223 now works as expected.
2020-05-28 00:34:45 +02:00
|
|
|
rgbColor.SetIndex(7, false);
|
2019-05-03 00:29:04 +02:00
|
|
|
color = rgbColor.GetColor(view, _defaultFg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[7], color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultFg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[15], color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultBg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[7], color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultBg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[15], color);
|
|
|
|
|
|
Fix SGR indexed colors to distinguish Indexed256 color (and more) (#5834)
This PR introduces a new `ColorType` to allow us to distinguish between
`SGR` indexed colors from the 16 color table, the lower half of which
can be brightened, and the ISO/ITU indexed colors from the 256 color
table, which have a fixed brightness. Retaining the distinction between
these two types will enable us to forward the correct `SGR` sequences to
conpty when addressing issue #2661.
The other benefit of retaining the color index (which we didn't
previously do for ISO/ITU colors) is that it ensures that the colors are
updated correctly when the color scheme is changed.
## References
* This is another step towards fixing the conpty narrowing bugs in issue
#2661.
* This is technically a fix for issue #5384, but that won't be apparent
until #2661 is complete.
## PR Checklist
* [x] Closes #1223
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
The first part of this PR was the introduction of a new `ColorType` in
the `TextColor` class. Instead of just the one `IsIndex` type, there is
now an `IsIndex16` and an `IsIndex256`. `IsIndex16` covers the eight
original ANSI colors set with `SGR 3x` and `SGR 4x`, as well as the
brighter aixterm variants set with `SGR 9x` and `SGR 10x`. `IsIndex256`
covers the 256 ISO/ITU indexed colors set with `SGR 38;5` and `SGR
48;5`.
There are two reasons for this distinction. The first is that the ANSI
colors have the potential to be brightened by the `SGR 1` bold
attribute, while the ISO/ITO color do not. The second reason is that
when forwarding an attributes through conpty, we want to try and
preserve the original SGR sequence that generated each color (to the
extent that that is possible). By having the two separate types, we can
map the `IsIndex16` colors back to ANSI/aixterm values, and `IsIndex256`
to the ISO/ITU sequences.
In addition to the VT colors, we also have to deal with the legacy
colors set by the Windows console APIs, but we don't really need a
separate type for those. It seemed most appropriate to me to store them
as `IsIndex256` colors, since it doesn't make sense to have them
brightened by the `SGR 1` attribute (which is what would happen if they
were stored as `IsIndex16`). If a console app wanted a bright color it
would have selected one, so we shouldn't be messing with that choice.
The second part of the PR was the unification of the two color tables.
Originally we had a 16 color table for the legacy colors, and a separate
table for the 256 ISO/ITU colors. These have now been merged into one,
so color table lookups no longer need to decide which of the two tables
they should be referencing. I've also updated all the methods that took
a color table as a parameter to use a `basic_string_view` instead of
separate pointer and length variables, which I think makes them a lot
easier and safer to work with.
With this new architecture in place, I could now update the
`AdaptDispatch` SGR implementation to store the ISO/ITU indexed colors
as `IsIndex256` values, where before they were mapped to RGB values
(which prevented them reflecting any color scheme changes). I could also
update the `TerminalDispatch` implementation to differentiate between
the two index types, so that the `SGR 1` brightening would only be
applied to the ANSI colors.
I've also done a bit of code refactoring to try and minimise any direct
access to the color tables, getting rid of a lot of places that were
copying tables with `memmove` operations. I'm hoping this will make it
easier for us to update the code in the future if we want to reorder the
table entries (which is likely a requirement for unifying the
`AdaptDispatch` and `TerminalDispatch` implementations).
## Validation Steps Performed
For testing, I've just updated the existing unit tests to account for
the API changes. The `TextColorTests` required an extra parameter
specifying the index type when setting an index. And the `AdapterTest`
and `ScreenBufferTests` required the use of the new `SetIndexedXXX`
methods in order to be explicit about the index type, instead of relying
on the `TextAttribute` constructor and the old `SetForeground` and
`SetBackground` methods which didn't have a way to differentiate index
types.
I've manually tested the various console APIs
(`SetConsoleTextAttribute`, `ReadConsoleOutputAttribute`, and
`ReadConsoleOutput`), to make sure they are still setting and reading
the attributes as well as they used to. And I've tested the
`SetConsoleScreenBufferInfoEx` and `GetConsoleScreenBufferInfoEx` APIs
to make sure they can read and write the color table correctly. I've
also tested the color table in the properties dialog, made sure it was
saved and restored from the registry correctly, and similarly saved and
restored from a shortcut link.
Note that there are still a bunch of issues with the color table APIs,
but no new problems have been introduced by the changes in this PR, as
far as I could tell.
I've also done a bunch of manual tests of `OSC 4` to make sure it's
updating all the colors correctly (at least in conhost), and confirmed
that the test case in issue #1223 now works as expected.
2020-05-28 00:34:45 +02:00
|
|
|
rgbColor.SetIndex(15, false);
|
2019-05-03 00:29:04 +02:00
|
|
|
color = rgbColor.GetColor(view, _defaultFg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[15], color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultFg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[15], color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultBg, false);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[15], color);
|
|
|
|
|
|
|
|
|
|
color = rgbColor.GetColor(view, _defaultBg, true);
|
|
|
|
|
VERIFY_ARE_EQUAL(_colorTable[15], color);
|
|
|
|
|
}
|
