markers: update the problem-marker decoration

[vince-fugnitto]

What it does

Fixes #3819

The following commit updates the problem-marker decoration from the explorer to display the total count of errors and warnings for a given resource and updates container nodes (parent directories) to display a generic symbol. The following changes are aligned with the behavior with VS Code.

How to test

1. register error or warning markers in a given workspace
2. the explorer should display the updated marker decorations (count or generic badge)

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

Signed-off-by: vince-fugnitto [email protected]

[vince-fugnitto]

I'm wondering if there is a better way to do this.
It'd be easy if I had access to the FileStat and could determine if the marker's URI is a directory or not.

[paul-marechal]

In this case, do only files have a marker? Folders wouldn't match anything?

You could write const isResource = new Set(this.problemManager.getUris()).has(marker.uri); and document why this test filters file from folders.

I don't see a clean way to get information about the filestat synchronously. Best we could do is make a bunch of modification to get data about the current node being decorated, and see what field we could add to the node (folder etc...)

[vince-fugnitto]

We will need to add a strategy when dealing with multiple tailDecorations in order to enforce a certain order. For example, we want to have markers before scm decorations:

4 M

and not

M 4

[vince-fugnitto]

We also need to merge the decoration for scm and problems for containers (parent nodes).

[elaihau]

I played with this change in my local environment. And I confirm it works as described in both single and multi-root workspace, with both warning and errors in a single file.

[vince-fugnitto]

I played with this change in my local environment. And I confirm it works as described in both single and multi-root workspace, with both warning and errors in a single file.

I'd like to see if we can be able to enforce an order for tailDecorations so that
problems can be before scm. As far as I know, nothing exists as of yet.

[akosyakov]

Anything else should be done here?

[vince-fugnitto]

Anything else should be done here?

@akosyakov I believe #7466 (comment) is blocking the pull-request at the moment.

[vince-fugnitto]

I pushed the changes to my fork and will revisit whenever I have some time: vince-fugnitto#9