Too many compilation triggers showing progress that isn't useful

[ckipp01]

Describe the bug

When using the new progress support added in this pr, which is great btw, you start to notice that there is a lot of compilation requests sent at times that we either don't need to, or really shouldn't be shown to the user. For example in the video below you see me just navigating to a definition in a java file and when I come back to the Scala file a bunch of progress notifications about compiling different modules start coming. If I do the same thing again, it happens again. When navigating around this can become very distracting as a ton of these can be sent for your codebase.

Screen.Recording.2024-02-07.at.15.00.19.mov

Expected behavior

I'd expect this to be a bit more restricted. The user obviously wants to know when compilations are happening and maybe that is blocking something from working as expected or as quickly as they want. However, in scenarios like this where all the user is doing is navigating back and forth from sources that have already been fully compiled, they probably don't want to see this.

Operating system

macOS

Editor/Extension

Nvim (nvim-metals)

Version of Metals

1.2.0+123-450514c7-SNAPSHOT

Extra context or search terms

No response

[kasiaMarek]

Since #6044, we always compile on didFocus, didOpen if the build target in focus changed to avoid complicated logic with keeping track of which inverse dependencies are influenced by previous compilations. We could not send progress for compilations that are done on didFocus, didOpen, and show only those on actions as didSave, though it feels a bit odd to make some compilations more meaningful than others.

[ckipp01]

In the example video though there wasn't a single change in any sources. So even in that scenario no matter what compilations are triggered? I believe in Bloop these would be marked as no-op compilations correct? Could we maybe filter out no-op compilations and not show those? I'm purely looking at this from a UX perspective, and without making any changes and just navigating around a fully compiling workspace I wouldn't expect to be constable seeing compilation progress notifications when things are fully compiled.

[kasiaMarek]

I see what you mean, I'm just not sure how to handle this reasonably.

So even in that scenario no matter what compilations are triggered?

Yes, every time build target in focus is changed.

Could we maybe filter out no-op compilations and not show those?

My guess is that we know it was a no-op after the compilation was finished. We could do some delay with the status, so very fast compilations (like no-ops) won't be shown. However, if things get slow on the build server side for whatever reason it might not work.

So far I see the following options:

1. add delay to status, so quick compilations are not shown,
2. don't show compilations triggered by specific actions (like didFocus),
3. make to logic of when a compilation should be triggered better.

[ckipp01]

Yes, every time build target in focus is changed.

Gotcha, didn't catch that before, but makes sense.

add delay to status, so quick compilations are not shown,

No, I don't think this is the way to go. Adding in delays just... make things seem delayed 😆 which they would be.

don't show compilations triggered by specific actions (like didFocus),

I also don't think this would be a good approach since there are situation (like the very first time you enter a target) that you would want to see that compilations are happening, since they need to happen.

make to logic of when a compilation should be triggered better.

Yea, I'm thinking this should be the path taken. I saw that with realizing that it'll be the trickiest. But again, I think we should look at this as a UX issue and really think about:

1. What information does the user need to know? Let's show it to them
2. What information is just noise? Let's avoid showing this

[ckipp01]

So I was playing around with this again today because I noticed in a minimal hello-world scala-cli project I was getting a bunch of duplicates. I've included the LSP logs to show that just opening a hello world scala-cli project, doing nothing at all sends 4 different "Compiling " $/progress notifications. The logs are here.

And the duplicate notification looks like this:

[Trace - 00:16:04 PM] Sending notification '$/progress'
Params: {
  "token": "5aef7eb8-421c-4b25-8ad5-fd5842cb6595",
  "value": {
    "kind": "begin",
    "title": "Compiling minimal_f4dd477a3a"
  }
}

I'm curious to try and trace these 4 to better understand exactly in that process what is triggering them because it seems a bit excessive to send 4 separate ones for doing nothing but opening a project.

EDIT: Alright, one more thing. I posted this on Discord, but I'll stick it in here too to have it all in one place. I noticed that multiple of them are also no-op compilations. I always assumed that you could only tell this after the compilation had happened, but I noticed multiple of these:

[Trace - 01:07:19 PM] Received notification 'build/taskStart'
Params: {
  "taskId": {
    "id": "2"
  },
  "eventTime": 1707998839458,
  "message": "Start no-op compilation for minimal_f4dd477a3a",
  "dataKind": "compile-task",
  "data": {
    "target": {
      "uri": "file:/Users/ckipp/Documents/scala-workspace/minimal/.scala-build/?id\u003dminimal_f4dd477a3a"
    }
  }
}

I think one of the things we are hitting on is that these are starting progress notifications when we can skip them. I looked into that but ultimately it seems that there is no field in CompileTask for this. So I think this would to change in the BSP spec here to include a noOp field just like the CompileReport has. Then in Bloop we'd be able to use this here when creating these to signify to the clients that this is going to be a no-op and you shouldn't display a progress notification for it. I started a convo about this in BSP here.

[tgodzik]

I think we invoke compile just in case in a couple of situations to make sure project is compiled. We might try to not do that, just only check the project is compiling or wait on an ongoing compilation.

As for Bloop we can skip the notification for sure, it's actually checked here

metals/metals/src/main/scala/scala/meta/internal/metals/ForwardingMetalsBuildClient.scala

Line 177 in d0bab71

statusBar.trackFuture(

Would be awesome to support a separate noop field to make it work across the build tools.

[tgodzik]

Fixed in Bloop, need a new release.