Inline Diagnostics

[pascalkuthe]

Closes #3272
Closes #3078
closes #1462
Closes #1953
Supersedes #6059

This PR implements inline diagnostics just like #6059. However, it also contains a streamlined virtual text API and significantly improves on the implementation in #6059.

The various improvements and bugfixes made to the virtual text API are currently part of this PR until it's been tested more. I will spin those out into a separate PR later. These should address the various bugs and panics discovered by poeple in #6059. Only the last commit contains an implementation of inline diagnostics.

Due to the changes to the virtual text API I had to essentially rebuild #6059 as most changes in that PR became unnecessary by the improvements in the virtual text API.

I also rebuild the ASCII rendering to support soft wrapping. Diagnostics which exceed the width of the screen are now soft wrapped automatically. Additionally, there is a minimum width setting for diagnostics. Any diagnostics so far to the right that there is not this minimum width available are displayed using a backwards arching line. See screenshot below:

Additionally, this PR implements a severity-based filter for diagnostics. This allows users to choose one of the following:

• a minimum severity for inline diagnostics: "warning"
• a list of severities to allow (useful if a certain LSP spams one particular severity). ["warning", "errror"] Using an empty list disables inline diagnostics

The diagnostics to display can be separately configured for the line that currently contains the cursor. By disabling diagnostics for all other lines users can therefore only display diagnostics on the current line too. By default, only warnings/errors are displayed, on the cursor line all diagnostics are displayed. I am open to changing the default here, but this did feel quite nice to use in my testing.

Additionally, some details of the soft wrapping can be configured.
Currently, a draft as this needs more documentation, a separate PR for most of the virtual text changes, and more testing. That said it should work quite well already, and I invite people to try this out.

[pascalkuthe]

(one test is failing for a type of virtual text that is currently not used yet. I forgot to clean that up, will look into that tomorrow, this shouldn't affect usage)

[carrascomj]

I noticed a bug (or strange behavior) trying this when combining wrapping with splits: on insert, the cursor moves away from the place where the actual insertion takes place.

See an example here: https://asciinema.org/a/DlnOVhiM8g2kXVtGBjwVFk8lo

(Maybe it is also a problem in master, mark as off-topic if that's the case).

[pascalkuthe]

thanks for testing! This is a new regression with this PR and doesn't occur on master.

[yuyidegit]

After merged this PR, LSP Type Hints #5934 have no effect.

[pascalkuthe]

Thank you for your feedback @yuyidegit] both bugs have been fixed (the test failures too).

This PR now depends on #6440 which fixes a bunch of bugs relevant to this PR. I will create another PR for the more complex virtual text API improvements once that one is merged

[gabydd]

found a pretty nasty bug to reproduce:

1. open helix running this pr in the helix repo
2. open helix-core/src/comment.rs
3. delete the s in lines on line 21
4. save the file so an error appears
5. scroll down the file till line 28 is the top line
6. when you go to the next line helix will crash with(some of the backtrace omitted that doesn't matter)

thread 'main' panicked at 'attempt to add with overflow', helix-term/src/ui/text_decorations.rs:136:16
 3: helix_term::ui::text_decorations::DecorationManager::render_virtual_lines
             at ./helix-term/src/ui/text_decorations.rs:136:16
   4: helix_term::ui::document::render_text
             at ./helix-term/src/ui/document.rs:166:17
   5: helix_term::ui::document::render_document
             at ./helix-term/src/ui/document.rs:79:5
   6: helix_term::ui::editor::EditorView::render_view
             at ./helix-term/src/ui/editor.rs:208:9
   7: <helix_term::ui::editor::EditorView as helix_term::compositor::Component>::render
             at ./helix-term/src/ui/editor.rs:1394:13
   8: helix_term::compositor::Compositor::render
             at ./helix-term/src/compositor.rs:170:13

I can reproduce this same panic for any inline diagnostic, seems like an edge case when the line that an error comes from does not fit on the screen. So the diagnostic would be the first line. But the first line rendered in this case would be line 27 which is technically row 2 so it has a visual_pos.row of 1 as well as nothing has been rendered last_line_pos.visual_line is equal to u16::MAX. because we are technically rendering the second line the check here passes https://github.com/pascalkuthe/helix/blob/c0f5627dd482de6266175e544c6ff2932c0f3925/helix-term/src/ui/document.rs#L160 and as last_line_pos.visual_line is u16::MAX and virt_off is 1, tada it panic.

[ocharles]

I just gave this a try and see to get a whopping big inline diagnostic that's much bigger than the diagnostic itself:

[pascalkuthe]

rebased and fixed the doc issues found above. Can't reproduce what @kanashimia shows. I think that may be an older build and is already fixed for a while

[kanashimia]

Can't reproduce what @kanashimia shows. I think that may be an older build and is already fixed for a while

That was on 418ac23 which was the latest build at that point. It is just slightly difficult to reproduce, as I said, because you need to have a very specific editor width and diagnostic for it to occur, for example rust-analyzer may change its output between versions.
Ideally it would be nice to just dump the editor state for you to see as a test, but I don't think it is possible.

I can still reproduce on commit 386fa37 obviously as nothing important was changed
rust-analyzer 1.81.0-nightly (4bc39f0 2024-06-26)
rustc 1.81.0-nightly (4bc39f028 2024-06-26)
cargo 1.81.0-nightly (4ed7bee47 2024-06-25)

And a terminal width
echo $COLUMNS $LINES
87 35

Here is a recording of it https://asciinema.org/a/cd8tFNbUwqCmcay91vXH1pKXB

Also multiple lines are still concatenated without a space for an eol diagnostic.

Well now that this was merged can just file a bug report.

[Narcha]

I can reproduce @kanashimia's issue, and I'm assuming it's caused by the line break in the 4th syntax error. There is a mismatch between the actual height of the diagnostics and the number of "virtual lines" inserted.

[aral]

@pascalkuthe It’s merged – yay! 🎉

Thank you so much for your 1yr+ of work on this.

💕

[blitzarx1]

Thanks for this long awaited feature <3. I have a stupid question:

I 've installed version from master helix 24.7 (22a05140), but my diagnostic messages are not inlined but in old top-right-corner style. Should I enable it somehow?

[mxmerz]

You need to enable it in the config, for example:

[editor.inline-diagnostics]
cursor-line = "hint"
other-lines = "error"

[blitzarx1]

Thank you @mxmerz! It helped! Thanks again to the contributors of this great feature.

[flippette]

tfw the feature you've been waiting a year for misses the release train by 1 day

Anyway, congratulations @pascalkuthe on landing this! 🎉

[karthago1]

@pascalkuthe thank you for this PR. Now I don't need to move my head to the upper right corner 😃 🎉