Build command in ST3 recently (I think) introduce a debug message (executed command, path, …) when executed command return an exit code <> 0.
But lot of compilers return non zero exit code when they encounter an error, so this is useless and make the result difficult to read.
Adding “quiet”: true to the sublime-build file remove all the output including the “[Finished in 0.4s]” message that is very useful to see when compilation is over.

So is it possible to either remove the debug message (or throw it to the console only) or always display the end message whatever the value of “quiet” in a next release ?

Thanks.

startup, version: 3092 windows x64 channel: dev

def finish(self, proc): if not self.quiet: elapsed = time.time() - proc.start_time exit_code = proc.exit_code() if exit_code == 0 or exit_code == None: self.append_string(proc, ("[Finished in %.1fs]" % (elapsed))) else: self.append_string(proc, ("[Finished in %.1fs with exit code %d]\n" % (elapsed, exit_code))) self.append_string(proc, self.debug_text)

Just comment out the last line in the code you referenced and override?

Yep, this is what I’ve done but overriding is not a solution, it’s only a workaround that can break for every new build you install.
IMHO this correction must be done in standard distribution.

It doesn’t break of you properly override by placing it in Packages/Default. I agree, however, that this is not a permament fix and that the feature request for this to be configurable is valid.

(Personally, I would not want to see this go. The PATH debug print is especially useful to me, and I would imagine others as well.)

if exec.py is modified in a new build, your overrided package will be the one that will be used.
So it can break anytime or at least you will not get the enhancement/bugfix from standard distribution.

Don’t get why you find more difficult to read the path in the console compared to the build output.
I think that it’s totally wrong to display a debug message when the return code of the compiler mean “compiled with errors”, like with JavaC.sublime-build.

And I’m sure that I’m not the only one finding this message useless (viewtopic.php?f=3&t=18768&start=0)

[quote=“bizoo”]if exec.py is modified in a new build, your overrided package will be the one that will be used.
So it can break anytime or at least you will not get the enhancement/bugfix from standard distribution.
[/quote]

Fair enough, but that doesn’t happen often, if it has at all.

I don’t usually have my console open, so I’d have to open it and run echo %path% compared to just looking a few lines below. The actual command run is also interesting when creating a build system and experimenting with parameters.

However, I do, again, understand that in some cases this is not desired, which seems to only be the case when the executable failed and provided debugging output by itself. This probably needs to be handled on a case-by-case basis.