add ability to show errors inline like VS Code(error lens)

[victororlyk]

Check for existing issues

• Completed

Describe the feature

It would be really nice to have ability to see the error inline without need to hover or go with cursor to that place.
I really love this extension, but I think it would be nice to have in the code of editor

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[fdionisi]

@victororlyk is not precisely the same as the error lens plugin, but have you already tried pressing f8 (and/or shift+f8)? It brings you to the next diagnostic and inlines the error.

[victororlyk]

@fdionisi yeah i have, those are cool, but I don't use f keys a lot. I have keyboard with f row and it is a bit annoying to use fs i use them only when it is really needed) https://happyhackingkb.com/. So a for me i just use vim keybinding to jump to the error for me it is faster) vim remappings would help ))

[diocletiann]

Agree. This is key feature still keeping me on JetBrains (with Inspection Lens plugin).

[probablykasper]

For context, error lens looks like this, with red/orange line and text:

[dumski]

Hi, any updates on this?

[barel-mishal]

any update also here?

[freidev]

Hello, thank you for all the great work you have done, it is a great editor, I just need this functionality to move from vscode to zed. 🚀

[panosdigital]

Any updates on this? This is really keeping from switching to Zed.

[KMJ-007]

any update on this?

i would really love this, it is a great experience to see errors in the same line, and don't need to hover my mouse over the error

[onkoe]

Hey there! I haven't touched Zed's extension system yet. However, if it's possible, I'd love to give implementing this a try!

If you're aware of whether this could be implemented through an extension, please let me know. :)

[kahlstrm]

Hey there! I haven't touched Zed's extension system yet. However, if it's possible, I'd love to give implementing this a try!

If you're aware of whether this could be implemented through an extension, please let me know. :)

I had a look at this issue but ended up just implementing some fixes around the already built-in diagnostics that you can navigate through. From that experience, I'd personally see that it would make sense to implement this as a built-in option (i.e. no extension), with implementation steps being the following:

1. Refactoring of the current diagnostic system to support having multiple diagnostics open at the same time: currently only one can be visible at once. A thing to keep in mind with this is the fact that one line can have multiple errors with different (or same) severities, e.g. Typescript + ESLint can easily cause multiple errors per line.

2. The displaying part: should only one be visible per line, if so, which one? How would the navigation behave w.r.t. this, as that should preferable always go through all diagnostics, instead of only the ones visible.

NOTE: I'm not affiliated with Zed, but would like to see this feature implemented, so shared my thoughts regarding the implementation.

[ActuallyHappening]

Still want this feature, whether as an extension or building setting to opt in

[ArbazSparkoSol]

I would prefer if this setting was built-in into the editor with the ability to toggle it on/off.

[beard-programmer]

Subscribing for an updates.

[divjakLab]

I am also looking forward to this one. The only missing thing to switch

[cv4x]

If you don't have anything to add to the conversation, you can simply "thumbs-up" the original post and click the subscribe button. There is no need to send emails and notifications to hundreds of people just to say some variation of "+1".

[beard-programmer]

Fair enough, thanks for sharing @claire-west
While I agree that a simple thumbs-up is less disruptive, it can sometimes go unnoticed and may not fully convey the importance of the topic.

You’re right that sending emails to everyone doesn’t contribute directly to the discussion, but it can provide the much-needed visibility and momentum to ensure the topic gets the attention and engagement it deserves.

[osiewicz]

It is easier for us to pick out an issue with high upvote count and read through comments that actually touch on the topic at hand rather than sift through a bunch of "+1's". Sending emails to everyone does not contribute directly to the discussion, nor does it add momentum. Please do not do that and just subscribe to the issue notifications instead (as @claire-west suggested).

[mikestonecodes]

I have indeed sinned, for I did utter "+1" in place of subscribing and giving proper favor unto the original post. I shall mend mine ways. Neither shall I henceforth reply to posts decrying the lack of substance, only to add naught myself. Yea, I shall refrain from such vain replies, that I may no longer contribute to the emptiness of the conversation.

[bitfield]

(comment on #17269)

This starts to get stale so I'll close it and emphasize again that the hardest part here is not even technical: we need to understand how multiple long line diagnostics are displayed on the same line; same as other pathological cases.

I think the proposal on the table is that for now, we do what VS Code does, which is to show as much of the diagnostic as possible at the end of the affected line, and truncate the rest. This is not perfect, of course, but it's something. The best doesn't need to be the enemy of the good here.

Perhaps an emoji vote would help to take the temperature of those watching this issue?

👍 show at least these truncated diagnostics
👎 nothing (status quo)

If there were a PR that did just this and nothing else, it might help us identify and solve any other blocking design issues that come up.

[caner-cetin]

This is not perfect

no it is perfect. there is nothing more needed. there is no need to chase for the perfection when the topic is as simple as showing errors inline that is it

[fmartingr]

(comment on #17269)

This starts to get stale so I'll close it and emphasize again that the hardest part here is not even technical: we need to understand how multiple long line diagnostics are displayed on the same line; same as other pathological cases.

I think the proposal on the table is that for now, we do what VS Code does, which is to show as much of the diagnostic as possible at the end of the affected line, and truncate the rest. This is not perfect, of course, but it's something. The best doesn't need to be the enemy of the good here.

(image)

Perhaps an emoji vote would help to take the temperature of those watching this issue?

👍 show at least these truncated diagnostics 👎 nothing (status quo)

If there were a PR that did just this and nothing else, it might help us identify and solve any other blocking design issues that come up.

My only nit from the implementation that was on a PR is that the errors were shown below the line, rather than on the side as ErrorLens does (on the screenshot). Truncating is fine. (Personally) I don't need the entire error or traceback or whatnot. I need to be able to see easily that there's a problem in a given line. More times than not I would be able to figure out what the error is without actually looking at the message.

[ArbazSparkoSol]

It would be even better if filenames in the tab and file explorer also change color to red to notify there is an error in the file just like in vscode.

[lamualfa]

Really need this feature when working on rust code.

[berkus]

To add to what @bitfield said:

in this image

if you click on the red error text, it should simply... navigate you to the Project Diagnostics window with this same error highlighted - and with the full diagnostic output; so if you know what rust means here you just fix it - if you need more details you can dive in.

[Release-Candidate]

What I prefer is having the message in the next line, which you can get with Sublime Text's linter plugin.

This shows a warning from the LSP to the right and the linter error message below:

[wigging]

Just showing my support for this feature. It's standard in Sublime Text and I would love to have it in Zed too.

[nilskch]

I occasionally use neovim for fun projects (but Zed is my daily driver), and I really like their way of displaying multiple diagnostics in the same line. They use the squares to indicate how many diagnostics of which type are in a single line:

From @SomeoneToIgnore in #17269 (comment):

emphasize again that the hardest part here is not even technical: we need to understand how multiple long line diagnostics are displayed on the same line

If we "copy" neovims way here we have a few advantages:

1. They already thought about this very problem and people seem to like it
2. Neovim transitioners feel more like home when they switch
3. Let's be honest, it looks awesome

I think for the implementation we could reuse a lot of the stuff that @mrnugget did in the git-blame feature. I like the spacing between the end of the line and the git blame line (not sure how its called). I would also like to expose the colors of the different inline diagnostics in the theme config.

If this sounds good to you, I can dig into neovims implementation and try to replicate it in Zed. (I think) I have enough time in the winter break to implement this, if we can agree on a design before :) Feedback is very welcome!

[berkus]

What I prefer is having the message in the next line, which you can get with Sublime Text's linter plugin.

This shows a warning from the LSP to the right and the linter error message below:

This breaks the code flow a lot, though.

[kuglee]

I like how Xcode does it:

[ActuallyHappening]

If we "copy" neovims way here we have a few advantages:

1. They already thought about this very problem and people seem to like it

2. Neovim transitioners feel more like home when they switch

3. Let's be honest, it looks awesome

I think for the implementation we could reuse a lot of the stuff that @mrnugget did in the git-blame feature. I like the spacing between the end of the line and the git blame line (not sure how its called). I would also like to expose the colors of the different inline diagnostics in the theme config.

If this sounds good to you, I can dig into neovims implementation and try to replicate it in Zed. (I think) I have enough time in the winter break to implement this, if we can agree on a design before :) Feedback is very welcome!

Yes I would love this!

[nilskch]

Following up on #4901 (comment): I was playing around a little bit and I imagine something like this:

Screen.Recording.2024-12-10.at.23.27.33.mov

Obviously this needs a ton of work; it would be great to get some feedback here (especially from the Zed team). I'm happy to implement any design that you suggest and I'm happy to iterate on different designs ideas with you to figure out what works best :)

I personally like the neovim way for inline diagnostics, but my personal opinion shouldn't matter here - we just need a starting point to iterate on in imo.

[uncenter]

That looks very good! I'm not even sure if I would change anything 😅

[sam-tredgett]

Following up on #4901 (comment): I was playing around a little bit and I imagine something like this:

Screen.Recording.2024-12-10.at.23.27.33.mov
Obviously this needs a ton of work; it would be great to get some feedback here (especially from the Zed team). I'm happy to implement any design that you suggest and I'm happy to iterate on different designs ideas with you to figure out what works best :)

I personally like the neovim way for inline diagnostics, but my personal opinion shouldn't matter here - we just need a starting point to iterate on in imo.

Would love to see this integrated and available for use, looks great!

[davisp]

@nilskch That looks great! I was planning on spending some time over the holidays looking into replacing my earlier PR with the same git blame approach. Have you pushed that branch anywhere, I’d love to give it a whirl!

[nilskch]

Hey @davisp, not yet. I just wanted to check if I can implement something that I'd like. I also wanted to wait for a yes/no from the Zed team before I spend more time on this and eventually waste their time with a PR for a feature that they do not even want.

I can tidy up the stuff that I did next week and push it to a branch. Would be awesome if we could make this work, I'm happy to help you on a V2 of your PR!

[davisp]

@nilskch Just bumping this before the holidays in case you forgot. I should have some free time over the holidays to look at this so any leg up I can get would be awesome. No worries if not, we can always compare notes after the holidays and combine efforts then.

[nilskch]

Hey @davisp, I created a draft PR in my fork (nilskch#1) to share what I did so far. It's not much and just the bare minimum to test some designs. I left a few comments with a few ideas.

I tweaked the text sizes slightly and I think this looks super nice and I would love to see this in Zed! Super happy that you want to give it a twirl!! :) Feel free to ping me if you want me to take a look (maybe on Discord since I don't want to spam 35 people? My Discord name is nilskch and I have the same profile picture). We can also do a pair programming session with the Zed collaboration tools on this sometime if you want?

@mrnugget @SomeoneToIgnore sorry for tagging you directly, but could you give us a short yea or nay from the maintainers perspective on this before you go your well earned holiday? If you don't like this design we don't want to bother you with a PR and don't waste time on this...

[davisp]

I spent some time hacking on this today and have gotten it to a place where I'm gonna start actually using it (though I've already been using it to hack on itself... which is kinda weird to be honest).

I attempted to duplicate what it vaguely looks like neovim does. I don't use neovim and I'm not gonna bother installing it. But I basically just ran with 1 box per diagnostic, properly colored, topping out a (currently hardcoded) max of 5 box indicators with a + when there's more than five diagnostics on a line.

The + is colored as a hint which seems to be a terrible choice. Also for some reason multple boxes end up being a few pixels different in height for some reason. I haven't got a clue why that is and nothing I tried fixed it. So it is what it is for now.

I should also note, that the speed in the gif I uploaded has pretty much been my experience regardless of what I was working on. The crates/editor/src/element.rs where this code currently lives is something like 8k lines and it was just as snappy. The only time I noticed latency was when I removed a brace and ended up causing probably hundreds of syntax errors. The editor was still just as snappy, but the actual diagnostics weren't popping in. I'm guessing that's in the LSP handling code somewhere. If memory serves, clangd limited diagnostics to the first 100 or something before it gave up. Perhaps rust-analyzer has something of that nature (granted that's a whole different issue/PR).

The branch I've been working on (courtesy of @nilskch, thank you for kickstarting this!) is by no means ready to be merged. Right now the logic is just plopped into the huge prepaint method. Cleaning that up is obviously straightforward so I'm not too worried about it. We'll also want to add configurability as right now its currently reading a couple inline git blame settings.

This also doesn't react very well to being mixed with inline git blame. I was hoping that'd just be magical but unfortunately they just both attempt to draw to the same location on screen.

Edit to add a link to the branch in case anyone else wants to give it a whirl:

https://github.com/davisp/zed/tree/davisp/nilskch/feat-inline-diagnostics

Also, steps to actually run this branch if you're curious:

1. Install Rust
2. Clone my fork, check out that branch linked above
3. Type cargo run --release in the root directory
4. Make a tea/coffee/whatever while you wait for it to compile. ~15m on an M1 MacBook Pro.

I haven't got any experience with the Linux or Windows ports so no idea if its that easy on those platforms.

[davisp]

So I ended up coming down with the flu or something which means I'm in no condition to Think Real Hard. However, it turns out that tweaking UI elements in a thing I barely understand in 5m compiler loops is a perfect cure to the boredom of being sick.

I'm not entirely sure if it was from a fever dream or not, but I also came up with an idea on how to display the extended diagnostics by hovering over the indicator to activate the diagnostic group using the existing machinery. I'm attaching another gif that shows how that works. Right now it's just a basic hover-to-activate ESC-to-deactivate sort of interaction similar to cycling through them with F8.

At this point I'm fairly happy with things. The biggest missing piece at this point is probably the lack of configuration and tests (I still have no idea how to test these sorts of things). I may try and figure that out later today but more likely it'll be later this week.

Ope! Edit to add I've also rebased this onto current main and code is on my branch as per usual:

main...davisp:zed:davisp/nilskch/feat-inline-diagnostics

[thejus-r]

Does this actually work with any language servers or only Rust?

[davisp]

@thejus-r It's not Rust specific. It should work just fine as long as the language server generates diagnostics. Below is a Python snippet for comparison.