Improvements to in-editor view of code coverage

[vogelsgesang]

While integrating Bazel's coverage reporting with VS Code's new coverage support (see bazel-contrib/vscode-bazel#366), I came across a couple of potential smaller UI/UX improvements.

Execution counts destroy code indentation

The counters which show how frequently a line / statement was executed lead to misaligned code.

In the screenshot above, this is particularly visible when looking at lines 37 and 39. While the if is aligned with the closing } in the original source code, this indentation gets distorted by the "1x" annotation on line 37.

For Java code this is only a smaller annoyance. For languages which rely on indentation for semantics (like Python), this makes the code much harder to understand.

Proposed solution: Render the annotation at the end of the covered region instead of at the beginning, as shown in the following mockup

Thereby, the coverage annotations don't distort the indentation and the indentation of the if still matches the closing }. This would also work nicely for coverage providers which provide statement coverage, i.e. with multiple separate regions within a single line.

Highlight complete lines for line coverage

Bazel and LCOV in general only provide line coverage and no statement coverage.
Currently, VS Code's UI seems to be tailored towards statement coverage, though: It highlights only parts of the line.
This leads to a visually rather "jagged" perception given each line has a different line lenhgt.

I would find it more visually appealing, if the complete line was colored (also including the empty space to the right of each line), similarly to how the complete lines in a git diff are highlighted as shown in this screenshot:

Proposed solution: Detect if a file only contains per-line coverage data (i.e. all position.column values are 0). If so, switch to coloring complete lines. It is important to do this detection on a per-file level and not on a per-coverage-report level, because Bazel can provide coverage runs across languages (Java, C++, ...) and hence for some files we might only line coverage, while for other files we might have statement coverage.

Tooltips on coverage regions provide little information

The text "was executed" provides no additional information. Whether the line is covered can already be seen based on the color. Similarly, execution counts (if available) are already visible in the code editor. Instead of this hover information, I would prefer to keep seeing the normal hovers provided by the language server.

Proposed solution: maybe just remove those tooltips?

Tooltips with branch coverage are inconsistent

There seem to be two different tooltips, as soon as branch coverage is available. When hovering on the line itself, we get:

But when hovering the red "?" mark towards the end of the line, there is more information in the tooltip:

Proposed solution: Remove the tooltip on the line itself (I want to see my language server's hovers instead) and only show it when hovering the red question mark?

Tooltips on line numbers hide the source code

The tooltip on the line numbers hides the actual source code.

line.coverage.mp4

This is a bit annoying, since I hover over the coverage gutter to see more information, but then the tooltip actually hides information, i.e. the source code.

Proposed solution: Maybe move the "Toggle inline coverage" button somewhere else? E.g., in this menu

or even as another button directly next to the "Split Editor" button visible in the above screenshot

[connor4312]

Thanks, these are good points

The tooltip on the line numbers hides the actual source code.

Yea, I'm not very happy with this and struggled to figure out a way to do this. If there's no mouseover hint, the ability to toggle inline coverage is pretty hard to find. People don't right-click things in general, and there's already a click action (selecting the line) on line numbers. The editor menu (in the top) is an okay solution but also harder to discover and not contextual with the line numbers.

[vogelsgesang]

🤔 could we maybe use a tooltip that opens to the left instead of to the right? That way it would obscure (parts of) the file browser instead of the editor