Don't show stack trace info in the cargo test output

[nixpulvis]

The general case for testing is to check for failures vs successes, with information about what failed given by a call to something like assert!. Stack trace information can be useful but often isn't.

[noseglid]

This was explicitly enabled by another user: b8bc438

I'd suggest you add it as an option.

[colin-kiegel]

Its not always the assert that panics. Therefore I would like to be able to see the backtrace. An option would be OK for me. :-)

[nixpulvis]

I'll update this to be an option later, I agree it should be. However I will argue that it should be off by default.

[colin-kiegel]

The option should also change this errorMatch: [ matchStrict, matchThreadPanic, matchBacktrace ] to errorMatch: [ matchStrict, matchThreadPanic ].

Default=Off is ok for me. Cargos default is off too.

[noseglid]

Cool. Off by default sounds good.

[nixpulvis]

This almost works, but the settings change doesn't get picked up until next load. I'm new to atom packages, how do you fix this?

[nixpulvis]

@noseglid also, off topic but, do you know how to make the output colored? This is really the only thing I miss about using the terminal directly.

[colin-kiegel]

@nixpulvis rust-lang/rust#27867 (comment)

[nixpulvis]

@colin-kiegel that's unfortunate.

[noseglid]

Should this be set for all commands?

[nixpulvis]

I thought it was a good idea, but I can see arguments either way.

[noseglid]

The other way to get colors enables is to spawn the commands in a pseudo terminal, and this it "thinks" it's running an environment which supports colors, control sequences, terminfo etc. This is something I'm looking to solve in the build package. It can't be solved by a provider. I'm more comfortable doing this now that term.js is the one controlling the output.

Regarding the update of the configuration. It doesn't update because build is not refreshing the setting from this build provider. Running Build: Refresh Targets would probably solve it.

I have written documentation on creating build providers. To make the update happen automatically you would in essence need to:

• Extend the EventEmitter.
• Observe the config variable and emit refresh everytime it changes:

atom.config.observe('build-cargo.showBacktrace', () => this.emit('refresh'));

This should cause build to ask for the settings once more, making this provider re-read the actual configuration and thus giving an updated response.

[nixpulvis]

Is this something that should be done for all settings in another PR?

[noseglid]

I'm absolutely fine with merge this as is, if you'd rather do it in another pr/not at all :)

[nixpulvis]

Yea if you don't mind, I'm not sure when I'll get around to the settings update stuff.