Some thoughts on server introspectability.

[ckipp01]

So the last couple days I've been playing around a bit with nvim-dap and adding a nice integration for it in nvim-metals. One of the things currently missing in Nvim built-in LSP is code lenses (for now, they should be coming soon), but that left me with following the instructions here on the website about debugging via simple commands. However, with these simple commands there is some information that is required from the user.

For Main classes:

• the main class itself
• the build target
• .. other stuff too but I want to use the two above as examples

For test classes:

• the test class
• the build target

When looking at this, this information is required to be put in by the user. However, it got me thinking why? This is information that Metals knows. Metals knows the build targets and Metals knows the main classes for all the available build targets. This then lead me down a rabbit hole of just reading various articles about the ability for introspection in IDEs and how there is an incredible amount of potential and possibilities when it comes to what the internal model of your IDE knows about your codebase, but may withhold. By withhold what I mainly mean is that it's not query-able. This quote from Pete Vilter in his article Codebase as Database: Turning the IDE Inside Out with Datalog really resonates with me:

But as I’ve used IDEs more, I’ve often felt that they have unreleased potential, because this rich internal model of the codebase is locked up within them, inaccessible except by painstakingly writing plugins using IDE-specific APIs.

Now that's a bit out of context, since he's talking about the IDE as a database, but it gets to the point I'm trying to make about the incredible amount of potential and knowledge that is inside an IDE. He does mention at times how IDE-specific APIs expose certain things, but at times I feel even that is currently not exposed in Metals apart from certain LSP extensions that we have created. I wonder if we could/should do more in terms of openess. I'm not talking extensions, but given my small example above, I'd love to simply:

• workspace/executeCommand build-targets -> and gets the build targets and then from that list... user then just picks one
• workspace/executeCommand test-classses build-target-id -> get those test classes from Metals.... user picks 1 or 3 of them
• and then run debug-adapter-start with the correct args that the user just chose

More or less this all happens behind the scenes when we generate code lenses to run / debug without the worksapce/executeCommands, but I wonder how great it would be to simply query that information ad hoc like this, and also what other cool things that would unlock. This would make the situation where a user doesn't have code lenses so much easier. I'm planning on playing around with at least exposing these (for an interactive way to select tests to run in nvim-metals), but I'm curious how many other situations there may be like this in Metals, and I'm curious to hear anyone else's thoughts on this. What else like this could we possibly expose to alleviate some manual work that developers have to do with their code bases or things they may wonder about their code bases that we could easily expose. This would obviously require work on the client side to actual use this info in a meaningful way, but I think that's quite doable.

EDIT:

After playing around a bit with #2483 I've even more convinced that this could unlock a lot of cool stuff. Mainly because it exposes to the client a representation of things that are build tool agnostic. I think it's quite powerful to provide information for clients to work with that is build-tool agnostics. The Scala ecosystem has some awesome tools, and it saddens me when they get intertwined into a build took quickly, often causing things to need to be redone in different places for different tools. It be awesome to unlock ways for new editor extensions. Now I realize I'm talking about a very small subset of tools seeing that there are like 6 of them, but after going pretty deep in the way Neovim does LSP, it allows for other plugins to also tie into things. So if a Nvim user wanted to make their own plugin that used something like metals/listBuildTargets to get some specific info about the class path and info about dependenies etc and build something around helping out users with this, it could easily be done, and done in a way that could be build-tool agnostic.

[tgodzik]

workspace/executeCommand build-targets -> and gets the build targets and then from that list... user then just picks one

I think that it might be useful to expose the information about build targets, though specifying it when running/debugging is currently totally optional. We only need it if there are more than one class with the exact same name, which only happens in really large codebases, which might have other problems, which we haven't even thought about.

workspace/executeCommand test-classses build-target-id -> get those test classes from Metals.... user picks 1 or 3 of them

This would be much more useful, since I imagine users might want to quickly run a test and simply choose if from a list. Although, I think in this case we could also add the possibility to just run the test in the current file, which might achieve the same thing and be much more convenient when there is a lot of tests.

[ckipp01]

I think that it might be useful to expose the information about build targets, though specifying it when running/debugging is currently totally optional.

Ah, if that's the case we should maybe change some of the info here as it makes it seem that in order to use debug-adapter-start you need to know the build target.

Ugh, read Chris, it says it right underneath.