-
-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding ...
when error is too long
#18
Comments
Hmm I don't know how common such long errors are, I don't run into them often enough to warrant dealing with the complexities of cutting text. |
Combined with the GitToolBox plugin, it can happen more often, but yeah, I guess it can be nice issue. Edit : here a small example that might be help in that regard : I guess it's ranked by error gravity and only the top one is shown. I believe it's actually better for lisibility. What do you think ? |
There are two problems with only showing one inspection.
It also wouldn't help with singular long errors. I'd prefer if IntelliJ had some way of globally configuring maximum width or number of inlays, so everyone could configure it however they wanted for all plugins. |
I understand your arguments. Just wanted to add this repo as an example on how this is handled by other plugins (here for nvim) : https://github.com/folke/trouble.nvim n this plugin, when there are multiple errors, only the "strongest" one is prominently displayed. You can identify the presence of multiple errors by the small circle at the beginning of the line; there's one circle for each error. So if you have multiple errors, you'll have as many circles as errors (colors being the same as the error gravity). This approach is quite convenient, in my opinion. Their philosophy essentially boils down to: "Prioritize fixing the most important issue first, so there's no need to clutter the interface with lesser ones." Anyways, I understand why you wouldn't want to go that way, I just wanted to add some new perspective. |
I've also just run into this, was wondering why me editor was suddenly super laggy after a test assertion over a JavaScript bundle failed and was inlined.
This was a single incredible long error.
You can just choose a large number that's big enough for pretty much any screen? |
When the error is too long, we should cut the error message adding
...
to avoid the scrollbar becoming so large.If we need more info, it's easer / faster to check the hint on hover.
What about lines with multiple errors ?
The text was updated successfully, but these errors were encountered: