Stop setting the background color when erasing #830
Comments
|
Interesting, nobody has complained about this on Linux or Mac where this should also be a problem. Have you tried removing this line? That might be all it takes. |
|
Yeah, that's weird. I'm tempted to suggest that most people probably set their background = black(ish) and foreground = white(ish) (or vice-versa) and don't use an extra color ... However, there are certainly a lot of, say iTerm color schemes, where the default background is not one of the base16 colors. E.g. BirdsOfParadise, Borland, Chalk, Desert ... I tried a couple of those in the new build last night but (as we've discussed elsewhere) I can't find a way to programmatically set the new color values yet. |
|
This is going to become critically important for a future Terminal update (1.2, 1.3). Since it launched, Terminal has been operating in a compatibility mode where the backing console acts as though the terminal setting @Jaykul mentioned is turned off. This has been the cause of a great number of issues, chief among them our inability to distinguish We're finally getting that fixed. We can differentiate colors set through the Win32 console API, by VT with the 0-8 color set (±brightness), and by VT with the 0-256 color set. old behavior
(I marked every translation as "mangled" here because we would first resolve the index to an rgb color known to the conhost in the middle of the transaction, then resolve the rgb color back to an index, and if that RGB color matched the defaults turn it into new behavior
Problem is, though, that due to the line @lzybkr pointed out PSReadline takes a ConsoleColor and maps it to a VT color. This means that we're reading out the foreground and background from win32 format (bottom of the table) and transforming it to vt (top of the table). Joel's assertion about black backgrounds unfortunately doesn't hold for our userbase. People love background images and acrylic, though I cannot quite determine why. The result looks like this (with my transparency exaggerated for effect):
|
|
And just to confirm, removing that line works great:
😄 |
In #6810, we introduced a "quirk" for all known versions of PowerShell that suppressed their requests for black background/gray foreground. This was done to avoid an [issue in PSReadline] where it would paint black bars all over the screen if the default background color wasn't the same as the ANSI black color. Years have passed since that quirk was introduced. The underlying bug was fixed, and the fix was released broadly long ago. It's time for us to remove the quirk... almost. Terminal still runs on versions of Windows that ship a broken version of PSReadline. We must maintain the quirk there -- the user can't do anything about it, and we would make their experience worse if we removed the quirk entirely. PowerShell 7.0 also ships a broken version of PSReadline. It is still in support for another 6 months, but updates have been available for some time. We can encourage users to update. Therefore, we only need the quirk for Windows PowerShell, and then only for specific versions of Windows. _Inside Windows_, we don't even need that: we're guaranteed to be built alongside a fixed version of PowerShell! Closes #6807 [issue in PSReadline]: PowerShell/PSReadLine#830 (comment)
As of Windows 10 build 18298, the new “Terminal” settings allow setting default ForegroundColor and BackgroundColor values which are separate from the 16 color "ConsoleColor" palette.
PSReadLine doesn't use the ANSI/VT escape sequence for default when erasing text, but instead overwrites the line with
$Host.UI.RawUI.BackgroundColor(e.g. when pressing backspace, or when using the arrow keys to navigate through the history buffer with commands of different lengths -- worse when some have multiple lines).PSReadLine needs to start using the "default" color, instead of specifying a color.
The text was updated successfully, but these errors were encountered: