zed
zed copied to clipboard
zed-industries
Typescript errors are un-dismissable if you click them
Check for existing issues
- [X] Completed
Describe the bug / provide steps to reproduce it
Clicking the hovering typescript error causes it to show up below the line, rather than as a popup above, and once its there there's no way to get rid of it.
https://user-images.githubusercontent.com/161135/230453398-088a3654-f303-421b-8dbd-2a10a7d8f4ef.mov
Environment
Zed: v0.80.5 (stable) OS: macOS 13.3.0 Memory: 8 GiB Architecture: aarch64
If applicable, add mockups / screenshots to help explain present your vision of the feature
No response
If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.
If you only need the most recent lines, you can run the zed: open log command palette action to see the last 1000.
No response
At the moment, esc should dismiss the error - a few others have found this a bit hard to discover and not super intuitive - not exactly sure what would be best for us to do.
esc does indeed dismiss the error. I'm curious what the purpose of the secondary (post-click persistent) state is, as it doesn't give any more info than the hover error.
esc does indeed dismiss the error. I'm curious what the purpose of the secondary (post-click persistent) state is, as it doesn't give any more info than the hover error.
It's funny that you point it out that the on-hover errors are clickable - I didn't even know that was a thing. What I recall is, we started with the inline errors and someone added the on-hover errors later on because they didn't want to use the keyboard to see the error. So we do have two systems that are a bit redundant. There is a slight difference though: with the inline errors, you can cycle forward and backward through the diagnostics with f8 and shift-f8. Also, the inline errors can be a bit more clear sometimes with multi-location rust errors.
Also, just noticed it, but it does seem like the inline errors show more (a warning in this case):
I'm guessing we just need to add warnings to our hover errors. Not really sure what we will do - if it makes sense to keep both or not.
At the moment, esc should dismiss the error - a few others have found this a bit hard to discover and not super intuitive - not exactly sure what would be best for us to do.
It would be nice if the diagnostics would disappear once the error is resolved (as suggested in #8397). Currently, I manually hit ESC after resolving the error as you said. I also found this hard to discover; I opened and closed the file a few times until I actively searched for the ESC solution.
I'm curious what the purpose of the secondary (post-click persistent) state is, as it doesn't give any more info than the hover error.
Sometimes there is additional information to the tooltip and sometimes there is not. In my opinion, it would be nice if the diagnostics only open if there is additional information to display (just my opinion, I would understand if you see this differently).
One more thing (that is not completely related to the issue): depending on the font size and theme, the text in the diagnostics looks very much like the code itself. The tooltip (the box when you hover the error) looks very nice! I think the diagnostics could use a little more styling. Maybe also a box? Not sure here.
This is also just my opinion. I found it a little bit confusing at times and I like the box more.
Let's close this issue out in favor of:
- https://github.com/zed-industries/zed/issues/5175