highlight files in the file explorer that have errors

[DmitryEfimenko]

Visual studio does it really well. I find it very helpful when working with TypeScript. I bet it would be as helpful with any strongly typed language.

[alexdima]

@egamma @bpasero Would be great to have this.

[xogeny]

👍

[ghost]

+1

[devdoomari]

any work on this?

[DarrylD]

this concept should also apply to git integration similar to Atom. Is it an api to handle this? Would be nice to start a PR.

[sachinnair90]

👍

[fabionogueira]

+1

[ibox4real]

+1

[jrieken]

This might happen in October as we are working on showing version control status in the file explorer (#178). As the screen shot shows we already have a running version of this. The red label represents a file with an error, the green label represents a file with a warning. The containing folder mirrors the most severe status. Most of my comment here applies to this issue.

[xogeny]

@jrieken I think orange would be a better color for warnings. Green conveys the sense that everything is perfect.

[DmitryEfimenko]

I think the choice of green color is due to the fact that code that has warnings in the code editor is underlined with a green line. Whichever color is chosen, it should be consistent. I'd vote to change both to orange too though

[CyberPunkCodes]

@jrieken - This would mess up Git color statuses, and the end result would be a messy, 20 different colors, Christmas tree, which a bunch of checking on which rule takes precedence. This would be a nightmare!

Atom puts a red squiggly under the filename. This should be the accepted way to do it. This example shows both a Git status of edited AND a lint error:

[jrieken]

@xogeny @DmitryEfimenko regarding the color we use for warnings: It's unlikely that we change the green default because we have been using it for long. But this is configurable; either by a theme or by settings. Add something like this to user settings and see warnings in orange

"workbench.colorCustomizations": {
  "editorWarning.foreground": "#d47b1c"
}

[jrieken]

We never documented this but you can run with this setting "problems.decorations.enabled": true to see errors & warnings in the editor. It will change the colour of an item and it will add an error-counter.

Give it a try and let us know what you think.

[rwmb]

@jrieken that's nice, but is there a way to show the errors when the file is not opened in the editor?

[jrieken]

but is there a way to show the errors when the file is not opened in the editor

Sure, but it depends on the extension... VS Code itself is pretty dumb when it comes to diagnostics. It just holds data in the form of "this extension owns this diagnostic-item for this resource" and renders it, e.g. as squiggles, in the status bar, in the explorer, and in the problems view. It's passive, so VS Code doesn't ask for diagnostics but extensions push diagnostics. We have done that because each language and project system has a different validation strategy, e.g you change TypeScript file a.ts and b.ts gets new errors. Only extensions know these things well and we rely on that. Reality is that some extensions do this really well and some don't. My recommendation is to reach out to them directly.

[IllusionMH]

So what will be the final implementation: Changing file name color or there is still a chance to see it implemented as squiggly underline?
I've used VS Code with "problems.decorations.enabled": true for several days and at this moment changing color is rather distracting, than helpful for me (for reasons mentioned above):

1. Lint errors make it harder to see git status of the file (there is still letter decoration, but color would be better)
2. Since at this moment extensions might remove errors/warnings status as soon as tab with file is closed causing it change color. And this was more noticeable than remove of underlines.

Pros:

• Same as other editors (WebStorm, Atom)
• Do not hides VCS status.

Cons:

• Harder to implement

[jrieken]

Yeah, what we'll be enabling by default will be what we have today. Mostly for the ease of doing it and because we want to collect more feedback on it. The biggest challenge we see with this is actually second point which is that most extension don't validate 'the project', because most have no notion of a project and because we don't expose the tab-model yet, see #15178.

Still, the first baby-step will be changing the default for problems.decorations.enabled to true, then comes more feedback, for sure ;-)

[mgaudet]

Just providing some feedback: I had to flip the problems.decorations.enabled pref back to false, because false positives in the C/C++ plugin are magnified hugely by this decoration.

[jrieken]

because false positives in the C/C++ plugin are magnified hugely

You mean they give fake errors? Do they know? It clearly is the weak spot of this feature... The editor itself doesn't control the data, it just renders it and when an extension provides stale, incomplete, or falsy data we now rub it into your face... I wonder if others, using different languages, have similar problems

[mgaudet]

Yeah, it is a known issue: microsoft/vscode-cpptools#871

[jrieken]

We will continue and finalise this in February

[reyalpsirc]

@jrieken Is there any way to enable only errors on the explorer?

[PhotoAtomic]

Renamig folders may cause many file to become "red" in error

looks like that at least the c# (OmniSharp - out of the box installed) extension should be active to trigger this error

to trigger the issue open a C# project (i've an asp.net core project)
it is supposed that the project have some nested folder and different c# file in each folder which make use of classes defined on other files
in general files in less nested folder hierarchy make use of classes defined in files in most nested folders.

i've a workspace file where i've added several of these folder to this workspace so to have them more handy accessible

take one of the nested folder and rename it, this obviously makes all the files in that folder hierarchy to change path

9 time out of 10 (to me at least) the files below the renamed folder become "red" in the explorer view, and may displays random errors (even if no actual error are present)

closing VS Code while the files are red (no modification applied) and re-opening it causes the file to return the correct color (no error are displayed as should be)

if compiling when the files are red, the compilation succeed but the files stays red

in fact no error are present but the folder renaming action very often appears to confuse the explorer view

[valleybay]

I could not understand what had happened when suddenly my explorer had been polluted with red text and red dots. I hope there is a way to disable this? I couldn't find it nested under explorer.disableThisSomehow

Edit: without disabling the feature in its entirety. Currently there's only problems.decorations.enabled, I'd love an option to disable it in the explorer, and keep it in the gutter.

[fiznool]

It would be nice if certain folders could be ignored when displaying errors in the sidebar. Currently my node_modules folder is constantly red because of some package inside which has 'errors' in it.

[DmitryEfimenko]

@fiznool: I prefer to completely hide node_modules folder from my explorer. It's not a proper fix for that issue, but might work for people like me:

"files.exclude": {
  "node_modules/": true
},

[jrieken]

Closing this issue because we have shipped the feature in January. Follow-up work is tracked with the file-decorations-label