new-scala-file command

[landerlo]

WIP new-scala-file. Still needs some polishing but this is a working new-scala-file command.

[ckipp01]

Thanks a lot for starting to work on this! How does this actually work though? Looking at it, I'd expecting that after the executeCommand is called (metals.new-scala-file) then Metals will respond with a window/showMessageRequest with the possible options. However, right now that's unhandled.

[landerlo]

Sorry, I forgot to update the setup file, I pushed the changes again with the new setup you need to change the setup as in the new setup example I pushed, declaring the inputBox and quickPick capabilities, so metals uses that.

The cancelling also works now.
I removed my 'rant' about metals not using workspaceEdits to create the file (I still think it'd have been better design than creating the file outside). But I see that it executes a GoTo to the created file, so we'll get the focus when we implement the GoTo command.

[landerlo]

Ok, the focus change is completed now, so this completes the functionality.
I was missing it uses GoToLocation commands to change focus.
You need to update your setup to the example setup here.

We'll need to think a way to have to manage setup and not having to change user config , when metals-nvim add endpoints or capabilities like in this PR.

Maybe instead of having to using the lua << whole setup code, have something like setup_nvim_metals { myOverrides }

[ckipp01]

Great job on this! Just a few comments/questions.

[ckipp01]

In what scenario is the directory_opt used here? Is this mainly for someone to use if they want to pass in a parameter?

[landerlo]

I've added the name_opt as well, so if any of those are passed it won't be requested in the UI. Passing the name is useful for the new symbol quickfix when we create the symbol under cursor. VsCode has that quickfix. It can be reused if we implement that code action, it's simply calling this function with the directory=nil, and name= word under cursor or missing symbol.
The directory is probably less useful but it's still an option supported by metals. In most cases people will just cd, but I can see -myself if I hafe time- using a fuzzy selection for all the existing packages and selecting destination. Maybe even using a full name: org.corp.NewClass that fills both the folder and the name into one call. Anyway, it doesn't add much code to support it. But feel free to remove if you think it's goldplatting.

[ckipp01]

I removed my 'rant' about metals not using workspaceEdits to create the file (I still think it'd have been better design than creating the file outside).

I don't exactly remember the reason, but I remember we had this conversation on the Metals side of things I believe and obviously didn't go that route. I don't remember the exact reasoning.

We'll need to think a way to have to manage setup and not having to change user config , when metals-nvim add endpoints or capabilities like in this PR.

Maybe instead of having to using the lua << whole setup code, have something like setup_nvim_metals { myOverrides }

Yea I've been thinking about this a bit lately and trying to figure out what a good balance between just offering everything and having the user set it up, or just doing it for them. I've noticed some plugins like completion-nvim for example just straight up override callbacks etc and all they require is to be included on_attach(). But I guess I'm not 100% sure that all users will want all the features this will hopefully have or not.

I also am watching this and seeing what happens. There is the chance that if the entire install goes away, it might make sense to just use Coursier here and add in the install/update/uninstall functionality. If we do that, then the next question is do we just handle the entire setup and not require nvim-lsp at all. /shrug

[landerlo]

If there is no update we can have a single nvim_setup that does everything, and user call it, and can override bindings or Commands after calling it. Maybe that f with all batteries included can be calling three funs for more fine grained like setup() (does the attach), default_bindings(), and default_commands() so somebody can pick and choose to not have any unwanted bindings. I personally like to have new functionality and bindings added with as little config as possible, but offering the pick and choose possibility. For me the test is that a feature like this shouldn't require me any changes if I've gone batteries included. NewScalaFile appears magically when I PlugUpdate
nvim-metals

[ckipp01]

I didn't realize this before, but on the Metals side, this is a bit odd to me that it's an array of two optional strings rather than

{
  uri?: string,
  filename?: string
}

[ckipp01]

If there is no update we can have a single nvim_setup that does everything, and user call it, and can override bindings or Commands after calling it. Maybe that f with all batteries included can be calling three funs for more fine grained like setup() (does the attach), default_bindings(), and default_commands() so somebody can pick and choose to not have any unwanted bindings. I personally like to have new functionality and bindings added with as little config as possible, but offering the pick and choose possibility. For me the test is that a feature like this shouldn't require me any changes if I've gone batteries included. NewScalaFile appears magically when I PlugUpdate
nvim-metals

I fully agree with this. I think it makes sense to merge this is, and then start moving towards a setup like that.

[ckipp01]

Thanks a bunch for work on this. LGTM 🎉