Building with JSON output prints JSON to output window

[randomPoison]

Printing the JSON-formatted errors to the build console isn't terribly helpful. At the very least I would have expected the console to not open when using JSON errors since there's very little useful output it can display (though there's likely still some). Personally I'd prefer to see the human-readable error formatting printed to the console, including niceties like coloring and filename/line numbers being clickable, but I don't know if it's possible to easily reconstruct the human-readable errors from the JSON output.

[randomPoison]

I looked through the configuration options for the atom-build package and found the option to not open the build panel by default. If possible I would still prefer the human-readable output logged to the build panel, but I'll leave it to the maintainers of atom-build-cargo to decide if this issue should be closed.

[alygin]

@excaliburHisSheath, there's the option 'Use JSON error format' in the atom-build-cargo settings. It's switched on by default. Just switch it off if you prefer the human-readable output. It supports colors on linux and macs.

The standard (human-readable) error output format has changed recently and there's a pending PR #63 that adds parsing of the new error format. Until it's merged and the new package version published, only JSON and the current error format (the one used in the stable Rust 1.11 by default) are parsed and displayed by Linter.

[randomPoison]

Hmm. While parsing the human-readable output seems like a good start, it's also a bit backward, isn't it? The point of rustc adding JSON output is to make things easier for tools like atom-build-cargo, so going back to parsing the human-readable output seems like a step backward. The more robust (though more difficult) solution would be to run the build with JSON output, parse the JSON output, then reconstruct the human-readable output when writing to the build panel.

That said, the current happy medium for me personally is to leave the build panel closed at all time, since the linter output is mostly what I want anyway. Being able to also see the human-readable rustc output would just be a nice bonus since the new error format is just so darn nice.

[alygin]

You're right, JSON output is aiming to provide a reliable way for IDEs to parse error messages. That's why it's used as the default option now.

But many (me included) like the standard output, so I've added its parsing. Atom Build doesn't support output overriding, so parsing JSON and producing the human-readable output from it is not an option now.

[colin-kiegel]

What if cargo could give both representations at the same time? Human readable via stout and json via stderr? I think atom build should not try to mimic this, or you will get a lot of bugs, that the mimicked human readable output deviates from cargo here and there... Just my two cents..

[alygin]

I agree that cargo-build shouldn't imitate human-readable output produced by rustc based on the JSON output even if it could. Though, it could add something to the output. For instance, to clearly delineate the boundary between the cargo/rustc output and the program output when the run command is used.

Till the RLS is implemented, I think the most we should do, is to extract all the useful information from the existing output, deliver it to the user in a convenient way by means of Linter, while letting him or her to look at the raw output when needed (ideally, we should remove such need at all).

[randomPoison]

I don't love it, but since RLS is the more robust solution long term I understand not trying to over-invest in the current system. Being able to more clearly see the output of the program when run would be a nice improvement in the short term.

[alygin]

I'm not quite understand what you mean by 'more clearly see the output'. Now, it's possible to have both the nice new human-readable errors in the output window and neatly organized Linter messages at the same time. What would be a more clear output?

[randomPoison]

Er, sorry, I was agreeing with your previous statement:

Though, it could add something to the output. For instance, to clearly delineate the boundary between the cargo/rustc output and the program output when the run command is used.

My current use case is that I want to always hide the build panel while building (since seeing the JSON output isn't helpful) but when running with cargo run example I want to be able to see the output of my program. So adding some kind of delineation between the two would be great, especially if I could get the build panel to only open once my program started running.

[oli-obk]

Then I'd say this is an atom-build feature request. We can't do much from this end. Either commands need to be able to specify whether to open the build panel, or we need a way to interleave instructions to open the build panel between the matched errors we encounter.

Multi-step commands have been suggested and declined.

[randomPoison]

Could atom-build-cargo not handle the multi-step part, though? If, for example, we wanted to run an example but not print build output couldn't it do cargo build example without showing the panel, then cargo run example and show the panel? I'm not familiar with how atom-build works so I don't know how much flexibility plugins like atom-build-cargo have over controlling those things.

[oli-obk]

nope, we have no control over that. Also, cargo run example would still contain the json output from the build, because cargo will obviously build the example before running it. We can't modify the output, but there are very preliminary and vague plans for a custom output panel that we can fill however we like (this might also enable us to have stdin when running programs).

[randomPoison]

Ah, I was also going to ask about that since I saw @noseglid suggest it for custom build output. In the meantime I think the atom-build feature I need to request is the ability to be able to specify panel behavior per-command, since I want the panel to stay hidden when doing cargo build, but I want it open when I do e.g. cargo run.