Change:
import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { IWorkbenchEditorService } from 'vs/workbench/services/editor/common/editorService'; import { LinkDetector } from 'vs/workbench/parts/debug/browser/linkDetector'; <ins> import { handleANSIOutput } from 'vs/workbench/parts/debug/browser/debugANSIHandling'; </ins> const $ = dom.$;

Discussion:
<!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version:1.22.1 OS Version:win10 Steps to Reproduce: use package to colorful my output (('hello')+" world") this will output string "hello world" that "hello" with color green(debug console,terminal) this work fine in v1.21.1 upgrade to v.1.22.1,it still work fine in terminal,but not work in debug console, all the text color is green,not only 'hello' terminal: ! debug console: ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No yes
I also noticed this after the update. !
this seems to have broke with your pr Would you be interested in fixing this issue?
Yeah I definately can, but not for a little while. If someone else wants to take a crack at it in the mean time go right ahead!
great. Tackle it when you have time then, assigning this to May so we do not hurry.
Hey I'm working on this issue now. While I was looking at the code again, I've noticed discrepencies in the way that various ANSI codes are being handled. This, in combination with the issue that prompted my changes originally, have led to a rewrite of the whole ANSI handling function. It should be much more robust when I'm done, but I have a question regarding your preference for currently unsupported ANSI codes. This code for example is currently unsupported by us: ! Would we like to print out , or hide the code on the debug console entirely? The actions taken currently vary substantially, so I'd like to define a specific way of handling situations like this. Certain codes such as (which is completely invalid) are currently ignored, while the code mentioned above is printed to the console as .
first of all thanks for looking into this. As for what to do in that specific scenario: my preference would be to not show it because that would be consistent with some other places where we However I could also be convinced to show it if you are leaning towards that.
Sound good. Unless you think it really matters, I'm going to match all numbers from 0-107 as valid codes despite certain ranges not really being included as real ANSI codes.

() While I'm at it, I'm adding background colours as they're not currently supported. I'd like to add high-intensity colours too, but the colours all seem a bit off. I wanted to check, are there any sort of guidelines for maximum colour intensity? Certainly on the dark theme, yellow looks more like mud... !
great. Makes sense for ansi code ranges If possible try to split it in two PRs, the second one that adds background colors. As for the guidelines we do not really have them. If the color is exactly specified by ansi then there is not much we can do as we should not change it or make it lighter. fyi our designer
I haven't changed the actual colours at the moment, though I can if it's worth looking into. As stated in , the first commit in the pull request should be ignored, as it just provides the context of the other review.
Am I doing something wrong? Install Run code:No colored output: !
I believe you are doing everything right. Though we stil plan to support some missing colors, but green should probably be supported can comment more
this fails for me in Isiders but works fine when running out of source: light theme: ! dark theme: !
I can try again once there is a new insiders (though none of my changes should affect this behavior)
Probably the code relies on some source workspace detail that differs between the built and packaged product. Does it work for you if you build the packaged product locally?
Works fine out of source. Does not work in insiders and when built locally. The issue is that the output recieved from the adapter when run out of source nicely contains the anssi sequences. When using insiders the ansi characters are stripped. Assigning to also and to investiagte on the adapter side Looking at this file it seems like the same extension version is used in both cases It might be somewhere between the adapter and the UI the ansi sequences get stripped Out of source: ! Insiders: !
When running out of source the adapters are identical to the ones in Insiders (because they are loaded from the Marketplace). So it cannot be something in the adapter. (And when using an integrated or external terminal the colors show up fine too).

It is (again) the environment, stupid... When running Insiders from the command line, the colors work fine because the environment has been configured properly by a preceding login-shell or terminal emulator. And colors fail when running Insiders from the Finder where there is no preceding login-shell (and where VS Code tries to simulate the login behaviour but obviously fails for "color"). And when using an integrated or external terminal colors work fine because both run as login-shells and are terminal emulators. See for more background info in .
great catch and good anlaysis. Thanks! Should we close as duplicate then?
No, has the background info but would not fix this. Leave it open until I understand the problem (and a workaround/fix).
The npm module "colors" () relies on  and some environment variables to figure out whether colors are supported. Since the debug console in VS Code is not based on a TTY, the check fails and becomes a no-op. In addition VS Code does not define any of the environment variables used in "colors" when launched from the Finder. As a workaround we could use an undocumented "FORCECOLOR" environment variable of the "colors" module: However this workaround would only work for the "colors" module and probably not for anything else. So adding this variable to the VS Code environment automatically, doesn't help much (and I'm not planning to fix this issue on the VS Code side). I suggest that the "colors" module documents the use of and the "FORCECOLOR" variable so that the workaround becomes more obvious.