Show all diagnostics as annotations

[rchl]

It's a quick and dirty implementation to test things out.

[rchl]

• It can be noisy
• Diagnostic annotations have priority over code action annotations so code actions are hidden behind "hover" action. Or possibly it will even be random which ones are prioritized.
• Ideally the most severe diagnostics would be prioritized (showed without hovering) but it's the opposite way right now since annotations and regions are added by the same add_regions call, and regions need to be added in the opposite order to annotations

[daggy1234]

Hey super excited for this feature. Just a few caveats:

1. It would be nice to make the colors less dark, perhaps more transparency
2. Some more padding on the surrounding boxes (just for readability)
3. Perhaps like errorlens color the text as well? (white doesn't go well on all colors) . By which I mean a much lighter background accent color on which darker colored text that matches goes.

These would be my choices however, feel free to interject!

[rchl]

• It would be nice to make the colors less dark, perhaps more transparency

I don't think it's possible to apply transparency to the background of those annotations.

2. Some more padding on the surrounding boxes (just for readability)

Where exactly? Top and bottom padding is probably not a good idea because then it could get taller than line height.

3. Perhaps like errorlens color the text as well? (white doesn't go well on all colors) . By which I mean a much lighter background accent color on which darker colored text that matches goes.

Can experiment with that.

[rchl]

This is with the text color defined and no background. Compare with the first screenshot.

[Zomatree]

When hovering over an annotation it seems all other annotation's text color changed:

[rchl]

When hovering over an annotation it seems all other annotation's text color changed:

Yes. Looks like annotations don't play that well with custom styling. It works better when just overriding text color. Just pushed that change.

[Rapptz]

Thanks for taking the time to implement this! At first glance, I like it. Though I imagine this would probably require new settings for people who don't prefer this view. Error lens lets you configure the range of severity that you care to show. Obviously there aren't any settings since this is just a draft PR.

Personally I couldn't get it to show all diagnostics, just the error ones. Not sure why that is.

[daggy1234]

This is with the text color defined and no background. Compare with the first screenshot.

Looks fantastic!

[eproxus]

How would this look if you actually had a more "normal" line width where errors overlap the code? (I realize some people might have very wide editor panes, but I certainly don't).

[rchl]

The errors would never overlap the code. Those are always shortened to fit the available space.

[rchl]

Still experimenting.

Brought back the code from the original @rwols' branch that showed annotation only for the diagnostic under the cursor.

I think the behavior of this should be customisable. So at least have those options:

• show annotations for all active diagnostics
• show annotation only for the diagnostic under the cursor
• ...?

The fact that we can't control what has priority in the annotation when there are multiple in the same region is a bit of a problem because what can happen is that on moving the cursor to a diagnostic, the diagnostic annotation will show up for a moment only to be replaced by code actions a moment later.

I feel like to solve that properly we would need either some support for prioritizing in the ST API or have a proper region/diagnostic manager class that would control the order and "drawing" of all those things from one central place. That would be major undertaking but I think that would also be needed if we would want to have some proper "problems panel".

[rchl]

I feel like to solve that properly [...] have a proper region/diagnostic manager class that would control the order and "drawing" of all those things from one central place. That would be major undertaking but I think that would also be needed if we would want to have some proper "problems panel".

One more advantage - should allow implementing proper support for navigating to next/previous diagnostic instead of relying on native next/previous_result commands which don't always work as expected.

[dmilith]

As an alternative, the Rust-Enhanced package does a similar thing already (just not inline): https://github.com/rust-lang/rust-enhanced

[rchl]

Specific to Rust so not much of an alternative for many, is it? :)

[TerminalFi]

Have we played with showing diagnostics as phantoms below the issue?

[rchl]

Have we played with showing diagnostics as phantoms below the issue?

I would consider this to be probably the worst option since it would make the content jump up and down constantly and create gaps in the code that would make it less readable.

[TerminalFi]

Have we played with showing diagnostics as phantoms below the issue?

I would consider this to be probably the worst option since it would make the content jump up and down constantly and create gaps in the code that would make it less readable.

I might work on an implementation for POC. I personal would prefer it based on my hacked together implementation. I don't image code jumping a ton unless you have a ton of diagnostics.

[TerminalFi]

Just for reference

[rchl]

I've decided to abandon the option for showing all diagnostics inline and only support displaying inline diagnostics for the current cursor. The other option could be added in the future if needed.

As far as the conflict between code action annotations and diagnostic annotations, I can't solve it currently so just warned about the incompatibility in the setting description.

[predragnikolic]

I used this for 2 days. Here are my conclusions so far.

This works as expected, when setting "show_diagnostics_inline": "at-cursor", the diagnostics is shown in the annotation:

In my daily use, I tend to use next_result, prev_result commands:

    { "keys": ["alt+3"], "command": "next_result" },
    { "keys": ["alt+1"], "command": "prev_result" },

And when I do that in combination with "show_diagnostics_inline": "at-cursor", I get the following result:

Note: the popup shows up each time I navigate to the next previous result, so we end up showing diagnostic information in both the popup and annotation, which looks redundant to me.

Plus, I have the"show_diagnostics_in_view_status": false, if I had that setting turned on I would see the same diagnostics on 3 places.

---

But at the end I think that some people would find this useful. ST also displays build errors in annotations. And the code is nice.

So this looks good to me.

[rchl]

I could work to try to add support for showing all diagnostics in the file (as a phantom below maybe).

[rchl]

Refactored by moving logic from DocumentSyncListener to SessionView. Mainly to be able to remove regions when SessionView is destroyed.

[rchl]

Note: the popup shows up each time I navigate to the next previous result, so we end up showing diagnostic information in both the popup and annotation, which looks redundant to me.

I find it that I quite often have to show the popup anyway as there is not enough space in the annotation to tell me what's wrong (talking about those long-winded typescript type errors). I guess ideally the annotation would expand automatically instead but that's not possible.

[NEX-S]

COOOOL STUFF! Thank You! Though I'm freshman for sublime text, I'm wondering how to using this branch in sublime and active the annotations diagnostics in sublime text, :D

[FichteFoll]

Since SublimeLinter more or less recently got support for annotations, I've been using these with great success and it looks as follows (second is when hovered):

I solved the noisiness by only showing the diagnostics' code, expanding to the full message text when hovering (including multiple diagnostics if any), which I believe to be a very elegant solution. The configuration needed for this can be found in my dotfiles repo.

As for diagnostics vs code lens, ideally LSP would be able to define a priority (either directly with the ST API or via a workaround where the last set of annotations gets appended to the list of annotations that ST renders) that a user can configure.

[rchl]

As for diagnostics vs code lens, ideally LSP would be able to define a priority (either directly with the ST API or via a workaround where the last set of annotations gets appended to the list of annotations that ST renders) that a user can configure.

ST API would be obviously preferred but not sure when or if we'd get that.

LSP can control the order but it would have to remove existing annotations and re-add them in case code action annotation comes when the diagnostic annotation is shown. That would likely create a bit of a flicker.

[rchl]

I've integrated @TerminalFi port of https://github.com/Maan2003/lsp_lines.nvim as a proof of concept.

I like the instant visibility of diagnostics without having to open the hover popup or hover diagnostics.

I don't like quite a few about it though...

• When typing, diagnostics can get created anywhere above the cursor. This shifts the view down and is both distracting, can hide the current line under the completions popup or can even hide the completions popup if the current line shift down far enough.
• Documents with many multi-line diagnostics can be distracting to look at and navigate within due to how phantoms work.

[rchl]

Here is a pretty bad case of the issue I'm talking about:

https://user-images.githubusercontent.com/153197/222897056-a8ba24e5-1626-4c84-ae68-9b0c98fea7ab.mov

[TerminalFi]

Glad to see someone found value. Hopefully we can get native Sublime support.

Text / font settings is one thing that needs test unless we can embed a font type

[TerminalFi]

Here is a pretty bad case of the issue I'm talking about:

https://user-images.githubusercontent.com/153197/222897056-a8ba24e5-1626-4c84-ae68-9b0c98fea7ab.mov

Yikes, almost need a longer debounce. I wonder how it works in VSCode and if they get the same experience. Also might be worth having it toggled and displayed on key press.