Skip to content
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

Closed
synopss opened this issue Jun 1, 2023 · 5 comments
Closed

Adding ... when error is too long #18

synopss opened this issue Jun 1, 2023 · 5 comments
Assignees

Comments

@synopss
Copy link
Contributor

synopss commented Jun 1, 2023

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.

image

What about lines with multiple errors ?

@chylex
Copy link
Owner

chylex commented Jun 1, 2023

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.

@synopss
Copy link
Contributor Author

synopss commented Jun 3, 2023

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 :

VSCode :
image
Intellij :
image

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 ?

@chylex
Copy link
Owner

chylex commented Mar 17, 2024

There are two problems with only showing one inspection.

  • It requires keeping track of which errors are on which lines, and dealing with changes in edited text that join/break lines, which adds complexity.
  • Seeing all inspections requires using a mouse, which somewhat defeats the purpose of the plugin, especially for anyone who has a large enough monitor for the inspections to fit.

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.

@synopss
Copy link
Contributor Author

synopss commented Mar 28, 2024

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.

@ForsakenHarmony
Copy link

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.

It also wouldn't help with singular long errors.

This was a single incredible long error.

Seeing all inspections requires using a mouse, which somewhat defeats the purpose of the plugin, especially for anyone who has a large enough monitor for the inspections to fit.

You can just choose a large number that's big enough for pretty much any screen?
We don't live in a perfect world, so compromises need to be made sometimes.

@chylex chylex self-assigned this Dec 26, 2024
@chylex chylex closed this as completed in 4c80573 Dec 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants