Missing libraries vs new "lime display failed" error

[Gama11]

This is a case where the new error is perhaps a bit misleading:

Too bad Lime handles -lib on its own, otherwise it could just be passed onto the Haxe Language Server, which would then create a proper diagnostic from it in the problems view. But I guess there isn't really a way for lime display not to fail here because of its custom lib handling...

[jgranick]

Perhaps the right approach is to test the Lime executable once on boot-up, and to display a message if this occurs. Otherwise, we only log to the console. This could occur due to any code compilation issue in the user's code as well

[Gama11]

This could occur due to any code compilation issue in the user's code as well

Such as? I can't think of any other scenario where lime display would fail / exit with 1.

I think it's actually good that this pops up in an error box so it doesn't fail silently anymore, it's just that the hints don't help much here (neither lime setup nor lime.executable will do much good). Perhaps we should check if the output begins with Error: and show the error in the popup box instead in that case.

[Gama11]

Another example:

The startsWith("Error:") check might be a good heuristic.

[joshtynjala]

The new 1.5.0 update of lime-vscode-extension includes a better experience when lime display fails.

• It doesn't suggest running "lime setup" as frequently. It now suggests this only when lime is not detected on the system path.
• Errors are now displayed in an output console instead of devtools. This should make the real reason for the failure easier to find, especially since it won't be mixed with other random JS warnings/errors in devtools that are usually not relevant.