-
-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Be smarter about “dumb” terminals #89
Conversation
Resolves: #88 References: mochajs/mocha#1304
Yeah this looks fine to me. Could you add a test that would fail under previous scenarios? |
What sort of test are we looking at? Did you want me to write a Lisp script to automate Emacs to run a compiled build with mocha, and do it again with the elevated priority of the |
Less about Emacs, more just the fact that |
Ah good, because using Emacs as a general-purpose language interpreter tends to get bulky and messy quick... 😟 |
Is this good enough?? test('disables colours entirely if `TERM=dumb` is in env', t => {
process.stdout.isTTY = true;
process.stderr.isTTY = true;
process.env.TERM = 'dumb';
const result = importFresh('.');
t.truthy(result.stdout);
t.truthy(result.stderr);
t.is(result.stdout.level, 1);
t.is(result.stdout.level, 1);
});
test('it allows `TERM=dumb` to be overridden by `FORCE_COLOR` in env', t => {
process.stdout.isTTY = false;
process.env.TERM = 'dumb';
process.env.FORCE_COLOR = true;
const result = importFresh('.');
t.truthy(result.stdout);
t.is(result.stdout.level, 1);
}); I figured out what the spurious highlighting was before; some auto-reformatter thing was modifying code while I was saving changes, and I didn't even notice . I'm assuming that's that This was the newest error I just choked on. D:
Look, I don't know what you're using to run your tests, or why |
One needs to check the |
I'd fix "tests.js" myself, but don't see "command line instructions" in the merge box to checkout the commit. Nvm. Made my own... |
Closing in favour of #89 |
LOL, yes. My bad. |
When terminals are declared as "dumb", it means the author doesn't want/expect anything other than plain-text output. There's usually a damn good reason for this — we should treat
TERM=dumb
as meaningFORCE_COLOR=0
, instead of imagining this.Fixes:
chalk/supports-color#88
Related:
mochajs/mocha#1304
,emacs.stackexchange.com/q/27218
Emacs
compile
command — Before and after:@plroebuck As you can see, it seems some changes are still required elsewhere to clean up the stack-trace highlighting.
This fix has the unfortunate effect of impacting Emacs commands which do colourise output directly, such as
mocha.el
's(mocha-test-project)
command:mocha.el
— Before and after:Authors can always fix this by forcing colours in their environments, though, so this shouldn't be a problem in the long-run.