Formatting errors to make them more readable

[vito-c]

I was wondering if it is possible to format errors so they are easier to read. For example:
error:

[bloop] [E] type mismatch;
 found   : cats.data.EitherT[scala.concurrent.Future,com.vito-c.long.long.long.package.name.CustomErrorClass,com.long.long.long.package.name.CustomResult]
 required: scala.concurrent.Future[com.vito-c.long.long.something.CustomThing]

What I was hoping is that there was a way to format code snippets via scalafix so you could tune how you wanted them in a global scalafix settings (maybe?) so the result would instead look like this:

[bloop] [E] type mismatch;
  found   : cats.data.EitherT[
    scala.concurrent.Future,
    com.vito-c.long.long.long.package.name.CustomErrorClass,
    com.long.long.long.package.name.CustomResult
  ]
  required: scala.concurrent.Future[com.vito-c.long.long.something.CustomThing]

and possibly supply a shorten setting it would only show class names when they are unique to the project universe?

[bloop] [E] type mismatch;
  found   : EitherT[
    Future,
    CustomErrorClass,
    CustomResult
  ]
  required: Future[CustomThing]

This would make it much easier to see what the error is. What are your thoughts? I'd love to help out with something like this.

[ckipp01]

Thanks for the question @vito-c! I moved this into the general feature request as this doesn't really pertain to coc-metals specifically, but rather to the format of diagnostics that Metals is actually receiving from Bloop in this case and forwarding on to the client.

I believe this question has come up before about very long diagnostics and how we could potentially shorten them to be a bit more precise. I know IntelliJ does a great job with this. As for having them be more (well actually less) precise but more succinct, that may actually need to happen in Bloop, or we'd need to truncate somehow in Metals.

What I was hoping is that there was a way to format code snippets via scalafix so you could tune how you wanted them in a global scalafix settings (maybe?) so the result would instead look like this:

I'm assuming you mean Scalafmt here and not Scalafix? I don't believe that would work as the entire diagnostic isn't valid Scala, so it wouldn't parse correct to format. So only the Scala code would have to be target after the diagnostic window would appear, the dialect would have to be set correctly because it's on the top level etc, so if I understand what you mean there it's probably not an easy task.

Hopefully others will have some more input about the possibility of getting diagnostics more succinct.

[tgodzik]

We do have a mechanism for shortening names that come from the presentation compiler, so it is in theory possible, although I imagine this can be a bit of work. The class responsible for that is ShortenedNames

[olafurpg]

Thank you for reporting! Diagnostics are reported by the build server as strings so I'm not sure Metals is the right place to fix this issue. I think it would be best to report this upstream to the compiler at https://github.com/scala/bug/

[vito-c]

@olafurpg I can report this on scala/bug for sure :)

Here are two thoughts I had for a work around:

1. The hacky way:
   supply a regex that gets applied to the error string s/[/[\n/g s/,/,\n/g I don't even know if this would be useful as you there would probably end up formatting things you don't want.
2. The less hacky way:
   I was thinking since metals already has the context of the project it could create a virtual file and then run that file through scalafmt. I think it would be difficult generate the file because you would have to pull out the pieces that are scala from the string error and then add the imports. Would something like that even be doable?

[vito-c]

What about making a compiler plugin? Would that be a way to tackle this?

[tgodzik]

That could work, although I imagine it could be a bit difficult. Maybe the plugin could use a custom reporter? Although, most benefit would be to include it in the compiler itself, which would work out of the box.

[laughedelic]

Have you tried using Metals with https://github.com/tek/splain? I think it does a good job of making error messages more readable and is going to be a part of Scala 2.13.4 (scala/scala#7785).

The only problem with using it is that it relies on colors quite a lot, but they get filtered out or ignored when displayed in the editor, e.g. when you see a type mismatch error Int|String without colors you need to remember what goes first: found or expected. But probably displaying colors is fixable.