Smoother main discovery when no mainClass is given.

[ckipp01]

Feature request and way to do it

Currently there is some manual work required to run a main class even if there is only one in your application, and your client doesn't have code lenses. We also handle the situation where we give a mainClass, but not the buildTarget. I'd like to be able to just give a buildTarget for example and have it also work. Even more so, I'd like to just give it nothing, and if there is only one main, it runs it for example, or if there are multiple then I'd like the server to show me and let me choose.

We can handle both of these already. I've been poking around and we already pretty much have the logic to do all this, but it all needs to be glued together. I've started to work on this already since I'd like to have a smoother experience for clients that may not have code lenses or don't want to use code lenses, but still don't want to manually have to enter the values. I also need this in nvim-metals for integration with nvim-dap 😬 .

The same concept should also be able to be applied to testing.

Sorry for breaking our own rules and creating a feature request here, but I'm already working on it...

Search terms:
running and debugging without code lens

[tgodzik]

I wonder if we could also send in a source file and/or position, which would start the class at the current document. That could make it a bit more general also in case we have more main methods or test suites.

[ckipp01]

which would start the class at the current document

What do you mean by this?

But yea I think we could totally have something that if you trigger in a specific file to run for example, it by default will run that build target (if it's possible), and then if it can't find a main there, then look in the other targets? And same concept for tests, etc. Like trigger it in file a and it tests a. Trigger it in b which is just utils, it does nothing, but returns options to run a, c, or d which are all tests. Something like that?

[tgodzik]

What do you mean by this?

So if we are currently in a main method or a test, we would invoke run/debug on that particular test or main method:

class MySuite extends FunSuite{
  test("simple"){
   CURSOR
  }
}

In the above scenario we would run the MySuite. Connected: scalameta/metals-feature-requests#72

[ckipp01]

So if we are currently in a main method or a test, we would invoke run/debug on that particular test or main method:

Ahhh of course, yea that makes sense.