scalameta / nvim-metals Goto Github PK

Task
Now that we are tying more stuff to this, it really should be enabled when people use it. I'm still hesitant to make it default since then it forces people to capture it in their statusline.

Task

In the TVP module the implementation of the Tree and the actual functionality that displays the UI is pretty closely coupled at the moment. I was able to extract the Node out and separate it, but the entire tree is more tightly coupled. It'd be nice to de-couple this from all UI parts of rendering the tree from the tree data structure itself.

Search terms

TVP tree ui

Disclaimer
I'm not sure if this is a nvim-metals, metals or neovim problem but reporting here first.

Describe the bug

When running commands like Fugitive's Gdiffsplit or Gitsigns' Gitsigns diffthis. The buffer opened to diff against has a name of the form: fugitive:///<path>/.git//0/my_scala_file.scala. This causes pretty intrusive errors of the form:

RPC[Error] code_name = InternalError, message = "Internal error." data = 'java.util.concurrent.CompletionException: java.nio.file.FileSystemNotFoundException: Provider "fugitive" not installed\n\tat jav
a.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)\n\tat java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)\n\tat java.
base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:704)\n\tat java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)\n\tat java.base/
java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2158)\n\tat scala.meta.internal.metals.CancelTokens$.$anonfun$future$1(CancelTokens.scala:40)\n\tat scala.meta.interna
l.metals.CancelTokens$.$anonfun$future$1$adapted(CancelTokens.scala:38)\n\tat scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)\n\tat java.base/java.util.concurrent.ThreadPoolExecutor.runWork
er(ThreadPoolExecutor.java:1130)\n\tat java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)\n\tat java.base/java.lang.Thread.run(Thread.java:831)\nCaused by: java.ni
o.file.FileSystemNotFoundException: Provider "fugitive" not installed\n\tat java.base/java.nio.file.Path.of(Path.java:212)\n\tat java.base/java.nio.file.Paths.get(Paths.java:98)\n\tat scala.meta.interna
l.metals.MetalsEnrichments$XtensionString.toAbsolutePath(MetalsEnrichments.scala:478)\n\tat scala.meta.internal.metals.MetalsEnrichments$XtensionString.toAbsolutePath(MetalsEnrichments.scala:475)\n\tat
scala.meta.internal.metals.DocumentHighlightProvider.documentHighlight(DocumentHighlightProvider.scala:25)\n\tat scala.meta.internal.metals.MetalsLanguageServer.$anonfun$documentHighlights$1(MetalsLangu
ageServer.scala:1333)\n\tat scala.meta.internal.metals.CancelTokens$.$anonfun$apply$2(CancelTokens.scala:26)\n\tat scala.concurrent.Future$.$anonfun$apply$1(Future.scala:659)\n\tat scala.util.Success.$a
nonfun$map$1(Try.scala:255)\n\tat scala.util.Success.map(Try.scala:213)\n\tat scala.concurrent.Future.$anonfun$map$1(Future.scala:292)\n\tat scala.concurrent.impl.Promise.liftedTree1$1(Promise.scala:33)
\n\tat scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:33)\n\t... 4 more\n'

To Reproduce Steps to reproduce the behavior:

1. Install fugitive or gitsigns
2. Open any scala file with metals attached.
3. Run :Gdiffsplit or :Gitsigns diffthis
4. See error

Expected behavior

Do not error and make metals ignore these buffers.

Screenshots

Installation:

• Operating system: Linux
• Nvim version: 0.5
• Commit of nvim-metals: af357ef
• Metals version: 0.10.

Discussed in #188

Describe the feature

I think this actually shouldn't be that hard to do. It'd be great to just show the doctor in nvim-metals, and we could do it as a floating window.

Task

We are using https://github.com/tjdevries/vlog.nvim right now for logging which is great. However, I find myself wanting some stuff to be shown to the user and other stuff to put into the logs. I also want what is shown to the user not to be exactly the same format as the logs. I think we can just re-use some of the existing logic if not all of it, move it around, and create a log.info function that takes a showUser boolean or something determines whether it gets shown and it can override the default.

Task

Right now the :Metals* commands are sort of bleeding into everything. This is the sort of thing I'd be annoyed at another plugin doing. Instead of just having them in the plugin/metals.vim file I should instead just move them into the attach functionality and first add them when the plugins is actually going to be used.

Additional context

Honestly, once we remove these the only real things left in here are the metals#status(), metals#errors(), and metals#warnings() functions. I'd like to just remove this too, but should ensure that there are easy replacements for them and that people are notified since this will be a breaking change.

Search terms

Stop leaking your dirty nvim-metals command everywhere.

Describe the bug

When using the nvim-dap integration to test, the output in the DAP-REPL shows the color codes. There is currently no way to turn this off when using using Bloop, and the same happens when using sbt.

To Reproduce Steps to reproduce the behavior:

1. Integrate with nvim-dap
2. Run a test
3. Look at the output in the DAP-REPL
4. See the following

With Bloop

With sbt

Expected behavior

There should be a way to turn color off

Additional context

• There is an upstream ticket for this in Bloop: scalacenter/bloop#1478
• I need to check to see if there is a way to turn this off when using sbt BSP

Search terms

DAP output

Describe the bug

When the tree is already open and you execute a reveal_in_tree() command you don't actually jump into the tree. There is some flickering of the tree to show that it is actually doing something, but not what we want.

To Reproduce Steps to reproduce the behavior:

1. Open tree
2. Go to a part of your source and execute reveal_in_tree()
3. Notice you don't jump into the tree

Expected behavior

Even with the panel open you should jump into it and go to the part of the expected tree.

Search terms

reveal in tree

Describe the bug

I haven't fully reproduced this yet, but it's been happening enough for me to report it, and then I'll try to figure it out.

To Reproduce Steps to reproduce the behavior:

1. Navigate around a bit
2. Execute the New Scala File command
3. Create a new object
4. At times it seems to create the file in the old directory you navigated from

Expected behavior

Create it in your current directory

Search terms

new scala file

Describe the feature

In my experience, metals/status has been a lot nicer than show-message. It'd be nice to just provide a function that users can put into their statusline integration to show this information.

Search terms

metals/status, statusline

When you have an integrated terminal open in nvim, running MetalsLogsToggle will say that logs are already opened.

To Reproduce Steps to reproduce the behavior:

1. Open any metals project
2. Open an integrated terminal
3. Run :MetalsLogsToggle

Expected behavior

A terminal is opened tailing metals logs

Actual behavior

Command things logs are already opened

Installation:

• Operating system: Linux
• Nvim version: v0.5.0-dev+1012-gfe1ebea33
• Commit of nvim-metals: 13635ad
• Metals version: 0.9.10

Search terms

metals, logs, terminal, nvim, toggle

Describe the feature

One of my most-used features in coc-metals is the New Scala File command. This quickly allows you to create a Trait, Object, Worksheet, etc.

Potential ways to implement?

In order for this to work we'll need to figure out how to implement the metals/quickPick extension.

Search terms

quickpick, New Scala File

Describe the bug

After exiting NeoVim, there's still a Java process running, which seems to be Coursier.

$ ps -ef | rg java
gvolpe    426860       1  9 14:55 pts/6    00:00:12 java -Xss4m -XX:MaxInlineLevel=20 -XX:+UseParallelGC -classpath /home/gvolpe/.cache/coursier/v1/https/repo1.maven.org/maven2/ch/epfl/scala/bloop-frontend_2.12... TRUNCATED

To Reproduce Steps to reproduce the behavior:

1. Open any Scala project.
2. Make use of Metals' features such as 'Go to definition'.
3. Exit NeoVim.
4. Run ps -ef | grep java or equivalent.
5. See Java process still running.

Expected behavior

The process is terminated when exiting NeoVim.

Installation:

• Operating system: Linux
• Nvim version: v0.5.0-dev+1309-g516551319
• Commit of nvim-metals: 69a5cf9
• Metals version: latest pulled by nvim-metals (not manually set)

Describe the feature

Basically I want to be able to just set metals_server_version to latest.snapshot and call :MetalsInstall at any time and get the latest snapshot installed. Part of the issue for this is that I can't figure out a way with Coursier to actually get the latest snapshot from sontaypt:snapshots. We even do a super hacky thing in Metals where we query the html page and grab the latest release that way to display in the docs.

Potential ways to implement?

Ideally just with a Coursier call to get the latest.

Additional context

Targeting -r sonatype:snapshots with Coursier to get the latest via complete doesn't works as I'd expect. It just gives you the stable releases.

Search terms

latest snapshot

Task

It would be great to have more info in here such as where the logs are located, where Metals is installed, and even what version of Java is detected.

• Where is Metals installed?
• Where is the nvim-metals.log file?
• What Java Version is being used?
• What settings are being set?
• lsp.log location from nvim

I don't think putting Java in here is a great idea since if a user is using Metals, sbt, or Bloop, there may actually Java mismatches between what Bloop may have been started with (depending if Metals didn't start it) vs what you have for running Metals.

Describe the bug

Creating a project using the scala3 template in metals and trying to use something that needs to be imported doesn't trigger a code action for importing it. If triggered manually, it says: No code action available

To Reproduce Steps to reproduce the behavior:

1. Create new project with metals.new-scala-project using scala/scala3.g8 template
2. Write a line in Main.scala using something that needs to be imported like Try, Future, UUID, etc

Expected behavior

A dialog should pop up prompting me to import the corresponding thing on enter

Installation:

• Operating system: macOS
• Nvim version: NVIM v0.4.4
• Commit of nvim-metals: af357ef
• Metals version: v0.10.0

Task

There is starting to be options that need to happen together to make sure things are working correctly. For example, if someone overrides the init_options.statusBarProvider, but then doesn't set the metals/status callback, it's not going to work, and there may not be a good indication as to why. It'd be nice to provide a health check that a user can run to ensure that what they have set up is what is expected.

Search terms
health

Task

There are a few places around the code base that I keep doing this:

api.nvim_set_var('metals_status', 'Something')

It might be nice to just make a helper function for this to use it with the metals/status callback and in the various places I use it.

Task

The main reason or this is to support the following workflow for me while developing:

1. sbt publishLocal giving me a new Metals snapshot
2. Assuming I already have the snapshot set as the metals version in my init.lua, do a :MetalsInstall to install latest snapshot
3. Then trigger the server restarting to shutdown the old server and load up the new one, hence never having to close my current project
4. Profit

Additional context

From looking a bit into this during stream, it looks like we can just use the vim.lsp.stop_client to achieve this, and then hopefully just re-use the intialize_or_attach method in setup.

There is also a :LspRestart in nvim-lspconfig that we can probably steal from.

Search terms

Restart server

Task

We should be able to use the newly added neovim/neovim#13285 to get all diagnostics instead of per buffer like they exposed before. This can replace the hacky way we do this now.

Search terms

workspace diagnostics

I jumped into the the LSP config discussion, I'd appreciate your thoughts there. I think using function composition and callbacks like in the POC I attached can greatly enhance the configuration of nvim for client initiated actions like definitions or references.

neovim/neovim#12277 (comment)

If that's not accepted in neovim, I'd like to provide something similar in nvim-metals to allow for the extra UI configurability.

Task

Right now it's quite bland. It'd probably look a lot better if it had a border, was more based off content width rather than screen width, and had better sections. There are multiple different plugins lately that made me realize how bad mine looks.

Additional context

For a couple reference points look at:

• https://github.com/kevinhwang91/nvim-bqf
• https://github.com/glepnir/lspsaga.nvim
• https://github.com/akinsho/dependency-assist.nvim

Search terms

floating window

At the moment we publish trimmed decorations as virtual text. The full hoverMessage is discarded.
The enhancement would allow to show the full decoration in a hover popup.

Nvim LSP has the functions to show the popup hovering markdown window but I am not sure if it supports the registering of the markdown popup.

decoration-nvim might be of inspiration, but it probably it's as simple as storing the hoverMessage per line when getting the decorations, then we would check whether the line has decoration.

I think the easier approach of having to call a function to check for the decoration and show it is preferable to automatic popup as there could be a lot of noise from big popups appearing when we traverse lines.

The option of popup after staying in a line for some delay could be a nice option, though it's better to have it in a separate issue on its own, so we have a decoupled staying long in line callback that can trigger these other behaviours.

Describe the feature

It'd be nice to provide a function that users can use to put into their statusline to display the total amount of Errors, Warnings, Info, etc. This could maybe be configurable to show per buffer or per workspace.

Potential ways to implement?

There may be some work from diagnostics-nvim that I could borrow. There is a change they may even implement this there.

Additional context

A lot of other LSP clients offer this, and I know with coc-metals I've gotten used to having this to be able to quickly glance at the count of errors.

Search terms

diagnostics, statusline

Task

Now that we have a logger added, go around the other parts of the code base and add in the logger where it's relevant.

Describe the feature

A nvim-dap integration would be awesome.

Potential ways to implement?

We'd have to change some of the init_options when we start Metals to make sure that debuggingProvider is set to true. We'd also need to figure out the configuration since normally in metals the run and debug are always triggered via code lenses. However, we should be able to work around that.

Search terms

debugging, nvim-dap

Describe the bug

Normally when you are adding in a Scaladoc and you're at this point /** Metals will give you a completion option for the full scaladoc of whatever you're over. This happens in the other Metals extensions, but seems to not be the case with nvim-metals.

To Reproduce Steps to reproduce the behavior:

1. Make a case class
2. Attempt to create a scaladoc
3. See that no completion items come from the server

Expected behavior

I'd expect to get the scaladoc completion item.

Installation:

• Operating system: macOS
• Nvim version: v0.5.0-dev+5ce328df4
• Metals version: 0.9.8+10-334e402e-SNAPSHOT

Describe the bug

nvim-metals creates a process when opening a Scala project, and it looks like it's not killed when nvim exits.

To Reproduce Steps to reproduce the behavior:

1. Open nvim in a Scala project.
2. Open any Scala file, which will trigger the start of the LSP.

   λ ps aux | grep nvim-metals
   miguel    861031 62.8  6.3 10007316 1029756 pts/4 Sl  12:59   0:56 /home/miguel/.asdf/installs/java/adoptopenjdk-8.0.282+8/bin/java -Xss4m -Xms100m -jar /home/miguel/.cache/nvim/nvim-metals/metals
   

3. Exit vim with :q. You can execute again the previous command to see the same process is still around.
4. Open the project again, and then a Scala file.
5. Check that there are now 2 nvim-metals processes.

   λ ps aux | grep nvim-metals
   miguel    861031 14.5  6.3 10003216 1029736 pts/4 Sl  12:59   0:56 /home/miguel/.asdf/installs/java/adoptopenjdk-8.0.282+8/bin/java -Xss4m -Xms100m -jar /home/miguel/.cache/nvim/nvim-metals/metals
   miguel    864326 22.7  6.3 10003216 1025104 pts/4 Sl  13:02   0:45 /home/miguel/.asdf/installs/java/adoptopenjdk-8.0.282+8/bin/java -Xss4m -Xms100m -jar /home/miguel/.cache/nvim/nvim-metals/metals
   

6. Exit nvim again with :q and check how the processes are still running.

Expected behavior

The metals process is killed when nvim exits, or it's re-used between instances.

Installation:

• Operating system: Linux
• Nvim version: v0.5.0-dev+1274-gbb3372792
• Commit of nvim-metals: 69a5cf9
• Metals version: 0.10.2

Search terms

process, exit

Task

A large improvement that can be made currently with the TVP implementation is that when a build target is compiled, the root node for that target is replaced. This comes in via the metals/treeViewDidChange. Now even if you have a bunch of stuff underneath that node expanded and nothing really changes in the nodes, the entire node chain is replaced.

Instead we should take a snapshot of that node and everything underneath it. We'll then need to do the retrieval again and then compare the trees to see what needs to be updated instead of just replacing the whole thing.

What this currently means is that if you have the tree open and expanded and you save, the tree will collapse since everything underneath was replaced.

Search terms

TVP caching.

Task

If a line is too long I literally just wrap on .. My initial lazy thought was that it would just break on a new sentence and then continue. However, when using excludedPackes it passes the line length and then tries to wrap on . and then wraps on every ....

Additional context

I really need to fix this.

Task

Right now in the tree the only distinction between nodes are whether one can be expanded or not, whether on is a method (signified via (), and that's it. However, the nodes contain symbol information about what type of Node it is. In coc-metals for example this is distinguished with colors. In VS Code it's done with little icons. This probably be made customizable.

Search terms

TVP Panel UI

Describe the bug

I just started receiving this error on build import:

You are using Scala versions 2.12.14, 3.0.0, which are not yet supported in this version of Metals. Please downgrade to Scala versions 2.12.12, 3.0.0-M3 for the moment until the new Metals release.

Installation:

• Operating system: macOS
• Nvim version: v0.6.0-dev+13-ga6cdfa27d
• Commit of nvim-metals: af357ef
• Metals version: 0.10.4+146-b5f79053-SNAPSHOT

Describe the feature

During my last stream it came up that there was a desire to have a way to not have Metals start on every time you enter a Scala project. While working a bit on another feature today I realized that this is actually quite doable, and quite easy. Realistically the initialize_or_attatch will still be called due to the auto command, but we can also have metals_start_by_default flag or something that if it's set to false, then upon the initialize_or_attach function being called, it won't auto start. Instead, the user would then have to manually use a :MetalsStart command or something similar. This would both start the server, but also set a flag for that workspace so that Metals knows to keep functioning as expected in that workspace as we keep opening up new Scala files.

Additional context

I'm adding in the :MetalsStartServer command as part of #118, so that should be finished first, and then we can tackle this.

Search terms

don't auto-start

Describe the bug

I have been following this Scala crash course on YouTube and I noticed that a number of diagnostics that he has in VSCode do not show up for me in Neovim. For example, at 53:32 he has a warning message show up which is not showing on my end.

To Reproduce

1. Create a new project, for example using sbt new scala/hello-world.g8
2. Open up a file such as src/main/scala/Main.scala
3. Import the build, wait for Metals to finish indexing
4. Introduce an error, such as changing println to priln

Expected behavior

An error diagnostic message should appear. Some diagnostics do appear, such as when changing object to obect, but some are missing. And I don´t know if this is related, but if there are multiple errors, only the first one is displayed.

Screenshots

Error is show as expected:

Multiple errors, but none are shown:

Error is inside the object:

Two errors, but only first one is shown:

Installation:

• Operating system: Linux (Void)
• Nvim version: v0.5.0-dev+1236-g1b030f889
• Commit of nvim-metals: 484f370
• Metals version: 0.10.2

Search terms

diagnostics, error, warning

Task

I know next to nothing about Lua testing, but the recent root_pattern function that was added is a prime suspect to be tested to ensure that the workspaces are actually being correctly set with nested build files. This seems to be working fine when testing manually, but it'd be nice to test this to ensure it.

Additional context

• I think busted seems likes a good choice to use.
• It looks like it looks in src for modules when testing, so I need to figure out how to get it to instead look in the lua directory, which is more common in nvim plugins. There is a -m flag that should work for this
• vim will be undefined when running the test, so I'm not sure how to get around that

Look for nvim plugins that are tested first.

Search terms
tests, busted

EDIT: Relevant comment from @tjdevries on gitter:

You need to run the test through neovims Lua runtime basically. It's a little difficult to set up in some ways.

Task

If a user first installs nvim-metals, then they will have to install Metals. Right now this is a multi-line print. It might be nicer to just make this a popup and show the welcome and instructions to the user.

Task

So looking at the docs fornvim_open_win() the config can just take a border argument. There is no title like I currently have, but it might simplify things a lot, which I'm all about. I sort of hate all the stuff I have in ui.lua, and I wouldn't mind literally replacing all of it if I could

Related to this, something else that has been on my mind is that there are certain things in nvim-metals that also part of https://github.com/nvim-lua/plenary.nvim. I think if we are going to start ripping stuff out and replacing it, it may be a good time to really go through everything and see what we could remove via plenary, and then just require plenary as a dependency.

Is your feature request related to a problem? Please describe.

When using Metals (via nvim-metals plugin) + DAP is there a way to provide arguments to methods when you're choosing which to run? When I tell it to Run it shows a prompt asking me to select the job and it just runs. Not sure how to pass arguments to it 🤔 It's unclear to me where DAP ends and Metals begins here though. So please feel free to close this or correct me if I'm wrong about something.

Describe the solution you'd like
When I am prompted on which job/task to run and I select it there could be a following prompt where I can optionally pass it args. I think a simple list of space separated arguments is fine just like how sbt does. I.E. In sbt if I'd run `sbt foo "arg1" "arg2" arg3" then the screen asking me for args would accept empty for no args or also just literally "arg1" "arg2" "arg3" for a series of string arguments.

Describe alternatives you've considered
There could optionally also be some sort of config file where you can specify the args for each job there. This would like be some .gitingore-ed file for most people. I don't love this nearly as much but might be a nice alternative if you're running the same task with the same args over and over. Although pressing up arrow should likely show you your previously used args in my initial solutions.

Additional context
None that I can think of.

Search terms:
DAP args arguments job task run debugger vim nvim

Describe the feature

Metals can publish worksheet evaluation using the Decoration Protocol. Nvim has support for this using virtual text, and this is implemented in coc-metals and it wasn't a ton of work.

Search terms

decoration protocol, worksheets

Describe the feature

When a user uses :MetalsInstall, it's really unclear that anything is going on. It just blocks until it's done. It'd be great to show some time of progress status while that is happening.

Potential ways to implement?

Maybe re-use the Metals status.

Search terms

Install progress

Describe the feature

One large thing missing in nvim-metals is support for the Tree View Protocol. One of the most useful parts of this is being able to explore external sources and having an easy way to jump from the symbol you're on.

Search terms

tree view protocol

Describe the feature

So both in this extension and in coc-metals I've sort of implemented half complete metals/status to benefit from the much better messages. However, that's only part of what metals/status can actually do. Take this example of when you try to run a program that has errors in the workspace:

[Trace - 09:21:01 AM] Sending notification 'metals/status'
Params: {
  "text": "$(error) Errors in workspace",
  "tooltip": "Cannot run or debug due to existing errors in the workspace. Please fix the errors and retry.",
  "command": "metals-diagnostics-focus"
}

There is a lot of extra information in here, but we only capture the text. Think of a way to be able to capture the tooltip and command.

Potential ways to implement?

I'm not 100% sure how to display this in an unobtrusive way. Maybe with a popup window of some sort, or just simply as a message with a choice that the user can choose to do the command or not.

Search terms

status commands

Just dropping this here to remind myself of this.

Question

The main question is how to correctly get the LSP support to handle the following situation:

|-app
| |-build.sbt
| |-src
|   |-main
|     |-scala
|       |-App.scala
|       
|-commons
| |-build.sbt
| |-src
|   |-main
|     |-scala
|       |-Util.scala
|
|build.sbt

Recommended or not, this is totally valid sbt build with the root build.sbt being the main one, and the others holding module specific information. The default settings have for the root patterns are the following:

root_dir = util.root_pattern("build.sbt", "build.sc", "build.gradle", "pom.xml");

This works as expected if you only have a single build file, and this even works in the above if you open the build.sbt file at the root. However, if you then cd into commons, the the client re-initializes with the server with another workspace root.

How is is possible to in this situation get it to correctly identify the correct workspace root and not re-initialize when you go into one of the modules?

Search terms
workspace root, multi-module, sbt

Describe the feature

Add this command in. It doesn't actually look like this is published in the Metals docs, so it's probably a good idea to fix that as well.

Potential ways to implement?

Just sending the command should be enough. Everything else is implemented.

Describe the bug

While we have build.gradle mentioned as a root pattern, if you open open a build.gradle file directly, then you are in a ft=groovy file, meaning the autocommand won't trigger, meaning that Metals won't start. You can just open a Scala file and everything will then work as expected, but I can also see how this can be confusing.

To Reproduce Steps to reproduce the behavior:

1. Get a gradle project
2. Open the build.gradle
3. See that it does nothing

Expected behavior

I'd be nice if nvim-metals would trigger on this.

Search terms

gradle

Task

Currently things like :MetalsInstall and :MetalsInfo (I don't actually think this one is needed) block since they take a bit of time. Instead of using os.execute and blocking we can swap those out to use vim.loop.spawn to do them in the background. I think this will be a better user experience.

Describe the bug

If you have a single Scala file in a standalone workspace that isn't part of a build and also isn't part of a git workspace, you'll see the following when trying to open it:

Error detected while processing FileType Autocommands for "scala":
E5108: Error executing lua /usr/local/share/nvim/runtime/lua/vim/lsp.lua:97: filename: expected string, got nil
stack traceback:
        /usr/local/share/nvim/runtime/lua/vim/lsp.lua:97: in function 't'
        vim/shared.lua:527: in function 'is_valid'
        vim/shared.lua:545: in function 'validate'
        /usr/local/share/nvim/runtime/lua/vim/lsp.lua:217: in function 'validate_client_config'
        /usr/local/share/nvim/runtime/lua/vim/lsp.lua:457: in function 'start_client'
        .../site/pack/packer/start/nvim-metals/lua/metals/setup.lua:178: in function 'initialize_or_attach'
        [string ":lua"]:1: in main chunk

This is because none of the root patterns find a root and nothing is given to the initialize_or_attach for the root.

To Reproduce Steps to reproduce the behavior:

1. Open a standalone Scala file that isn't in a git workspace
2. See error

Expected behavior

This should still work. In this situation we should probably just grab the parent directory and use that.

Search terms

Standalone Scala