René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Consider implicitly activating VT / ANSI escape-sequence support for native programs in `conhost.exe` console windows on Windows","articleBody":"### Summary of the new feature / enhancement\r\n\r\nThe following environments on Windows already automatically (and invariably) support VT / ANSI escape sequences in output from native (external) programs, notably to produce colored output.\r\n\r\n* Windows Terminal\r\n* Visual Studio Code's integrated terminal.\r\n\r\nBy contrast, in console windows (provided by `conhost.exe`) the support depends on a _registry setting_ that is OFF by default (`Set-ItemProperty HKCU:\\Console VirtualTerminalLevel -Type DWORD 1` enables it).\r\n(Note: Some CLIs explicitly enable VT support _for themselves_, using the WinAPI, `pwsh.exe` and `wsl.exe` being examples; these do _not_ depend on the registry setting, but all other ones do.)\r\n\r\nMaking VT support _implicit_ (independent of the registry setting) even for native programs seems worthwhile, to align with user expectations and a modern terminal user experience.\r\n\r\nGiven that the change only affects how data is _displayed_, there shouldn't be a backward-compatibility concern.\r\n\r\nImplicitly enabling support would also:\r\n\r\n*  simplify the code, given that VT support is currently turned off and on demand, given that it must be enabled for _PowerShell_ commands.\r\n\r\n* remove bugs in that context, such as  #18771 (which was inappropriately closed; a perhaps better repro is `cmd /c | Select-String Microsoft`)\r\n\r\n\r\n### Proposed technical implementation details (optional)\r\n\r\n_No response_","author":{"url":"https://github.com/mklement0","@type":"Person","name":"mklement0"},"datePublished":"2023-02-03T20:05:37.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":48},"url":"https://github.com/19101/PowerShell/issues/19101"}