Giter Club home page Giter Club logo

coc-metals's Introduction

coc-metals (Deprecated in favor of nvim-metals).

NOTE: coc-metals is now deprecated with last supported Metals version being 0.11.2. The official recommendation for Metals support in Vim is to use Neovim and nvim-metals. You can see the full context for this dececision here and you can find up-to-date instructins on Vim/Neovim support on the Metals webste. If you're a coc-metals user and would like to see continued support, I will still accept prs and provide guidance so feel free to reach out.

coc-metals npm code style: prettier Gitter

coc-metals is the recommended coc.nvim extension for Metals, the Scala language server. coc-metals offers automated Metals installation, easy configuration, Metals-specific commands, an embedded doctor, implementation of the decoration protocol, and many other small features.

NOTE: The readme is up-to-date with the main branch, so not all features will be available if you're using the latest stable release. The vim page on the Metals site is synced with the latest stable release

Table of Contents

Requirements

coc-metals works with both Vim and Neovim, but we recommend neovim for a smoother experience and extra features such as the decoration protocol.

  • coc.nvim - There are detailed instructions in their repo on how to get set up and running quickly.
  • Java 8 or 11 provided by OpenJDK or Oracle. Eclipse OpenJ9 is not supported, please make sure the JAVA_HOME environment variable points to a valid Java 8 or 11 installation.
  • Node >= 10 in order for coc.nvim to work correctly.
  • coc.nvim doesn't come with a default mapping for LSP commands, so you need to configure this in order for any of the commands to work. You can find an example configuration and instructions here

Installing coc-metals

Once you have coc.nvim installed, you can then install Metals a few different ways, but the easiest is by running.

:CocInstall coc-metals

If you install this way and are using the latest stable of coc.nvim, then daily your extensions will get checked to see if they are up to date. However, this is changing and has already changed in main. So in that case, you'll need to issue the :CocUpdate to update your extensions. If you install with this method youc an also see the version of your extensions by doing a :CocList extensions.

If you'd like to use the latest changes on main, but manage it using a plugin manager to download the extension, then if you are using vim-plug for example, enter the following into where you manage your plugins:

Plug 'scalameta/coc-metals', {'do': 'yarn install --frozen-lockfile'}

Then, issue a :PlugInstall to install the extension, and regularly a :PlugUpdate to update it and pull in the latest changes.

*** Keep in mind that if you are installing directly from the repo via :CocInstall with the repository url or through a plugin manager, remove coc-metals with :CocUninstall coc-metals before you add it in with one of the other methods to not conflict with one another.

Importing a build

The first time you open Metals in a new workspace it prompts you to import the build. Click "Import build" to start the installation step.

Build Import

  • "Not now" disables this prompt for 2 minutes.
  • "Don't show again" disables this prompt indefinitely. If you'd like to get this choice again, execute the metals.reset-choice command which will interactively allow you to reset choices that you've made for various things.
  • Use tail -f .metals/metals.log to watch the build import progress.
  • Behind the scenes, Metals uses Bloop to import sbt builds, but you don't need Bloop installed on your machine to run this step.

Once the import step completes, compilation starts for your open *.scala files.

Once the sources have compiled successfully, you can navigate the codebase with goto definition.

Custom sbt launcher

By default, Metals runs an embedded sbt-launch.jar launcher that respects .sbtopts and .jvmopts. However, the environment variables SBT_OPTS and JAVA_OPTS are not respected.

Update the metals.sbtScript setting to use a custom sbt script instead of the default Metals launcher if you need further customizations like reading environment variables.

sbt-launcher

Speeding up import

The "Import build" step can take a long time, especially the first time you run it in a new build. The exact time depends on the complexity of the build and if library dependencies need to be downloaded. For example, this step can take everything from 10 seconds in small cached builds up to 10-15 minutes in large uncached builds.

Consult the Bloop documentation to learn how to speed up build import.

Importing changes

When you change build.sbt or sources under project/, you will be prompted to re-import the build.

Build Re-Import

Configure Java version

The coc-metals extension uses by default the JAVA_HOME environment variable (via find-java-home) to locate the java executable.

No Java Home

If no JAVA_HOME is detected you can then Open Settings by following the instructions or do it at a later time by using :CocConfig or :CocConfigLocal which will open up your configuration where you can manually enter your JAVA_HOME location.

java-home

coc.nvim uses jsonc as a configuration file format. It's basically json with comment support.

In order to get comment highlighting, please add:

autocmd FileType json syntax match Comment +\/\/.\+$+

Using latest Metals SNAPSHOT

Update the "Server Version" setting to try out the latest pending Metals features.

After updating the version, you'll be triggered to reload the window. This will be necessary before the new version will be downloaded and used.

Update Metals Version

List all workspace compile errors

To list all compilation errors and warnings in the workspace, run the following command.

:CocList diagnostics

Or use the default recommended mapping <space> a.

This is helpful to see compilation errors in different files from your current open buffer.

Diagnostics

If you'd like to get all of the workspace diagnostics in your statusBar since by default you will only see the diagnostics for the buffer, you can find a section here in the wiki explaing how to do it.

Run doctor

To troubleshoot problems with your build workspace, open your coc commands by either using :CocCommand or the recommend mapping <space> c. This will open your command window allowing you to search for metals.doctor-run command.

Run Doctor Command

This command opens an embedded doctor in your preview window. If you're not familiar with having multiple windows, you can use <C-w> + w to jump into it.

Embedded Doctor

Worksheets

Metals allows users to create a *.worksheet.sc file and see evaluations right in their file. In Vim, this is done using comments that are inserted which will allow you to hover on them to expand. In Neovim, this is done using Neovim's virtual text to implement Metal's Decoration Protocol. If using Neovim, make sure to have the following line included in your .vimrc along with your coc.nvim mappings. Also keep in mind that the worksheet needs to be created inside of your project to have access to your dependencies etc. If you create them in the root of your project for example, your worksheet will only have access to the standard lib.

nmap <Leader>ws <Plug>(coc-metals-expand-decoration)

Then, when on the line that you'd like to expand the decoration to get the hover information, execute a <leader>ws in order to see the expanded text for that line.

Decorations with worksheets

NOTE Keep in mind that you can also directly import dependencies is your worksheet just like you would in an Ammonite script. This is a great way to try something out without changing your build definition.

Tree View Protocol

Tree View Protocol

coc-metals has a built-in implementation of the Tree View Protocol. If you have the recommended mappings copied, you'll notice that in the bottom you'll have some TVP related settings. You can start by opening the TVP panel by using the default <space> t. Once open, you'll see there are three parts to the panel. The first being the MetalsCompile window where you can see ongoing compilations, the second is the MetalsPackages window where you are able to see a tree view of all your packages, and finally the metalsBuild window where you have build related commands.

You are able to trigger the commands while being on top of the option you are attempting to trigger and pressing r. You can change this default in the settings. You can find all the relevant TVP settings below in the Available Configuration Options.

Goto Super Method

Depending on whether you're using Vim or Neovim, you'll have a slightly different behavior with this feature. If you're using Neovim, you'll want to ensure that you have codeLens.enable set to true in your Coc Config since you'll be able to quickly see via code lenses which members are overridden. Then, you'll be able to simply trigger a code lens action on the line of the member that is overridden. The default mapping for this is <leader> cl.

If you're using Vim, you'll still have access to this functionality, but you'll have to infer which members are overridden and utilize the metals.goto-super-method command.

There is also a metals.super-method-hierarchy command which will show you the entire hierarchy of the overridden method.

Goto super method

If you don't utilize this feature you can disable it by setting metals.superMethodLensesEnabled to false.

All Available Commands

You can see a list of all the available Metals server commands on the Metals Website.

You can also view these by toggling the CocList commands, which is <space>c with the default mappings.

Show document symbols

Run :CocList outline to show a symbol outline for the current file or use the default mapping <space> o.

Document Symbols

Available Configuration Options

The following configuration options are currently available. The easiest way to set these configurations is to enter :CocConfig or :CocLocalConfig to set your global or local configuration settings respectively.

If you'd like to get autocompletion help for the configuration values you can install coc-json.

Configuration Option Description
metals.enable Enable the coc-metals extension (default true)
metals.serverVersion The version of the Metals server artifact. Requires reloading the window.
metals.serverProperties Optional list of properties to pass along to the Metals server. By default, the environment variable JAVA_OPTS and .jvmopts file are respected.
metals.ammoniteJvmProperties Optional list of JVM properties to pass along to the Ammonite server. Each property needs to be a separate item. Example: -Xmx1G or -Xms100M
metals.javaHome Optional path to the Java home directory. Requires reloading the window. Defaults to the most recent Java 8 version computed by the locate-java-home npm package.
metals.sbtScript Optional absolute path to an sbt executable to use for running sbt bloopInstall. By default, Metals uses java -jar sbt-launch.jar with an embedded launcher while respecting .jvmopts and .sbtopts. Update this setting if your sbt script requires more customizations like using environment variables.
metals.millScript Optional absolute path to a mill executable to use for running mill mill.contrib.Bloop/install. By default, Metals uses an embedded millw script while respecting .mill-version file. Update this setting if your mill script requires more customizations.
metals.mavenScript Optional absolute path to a mvn executable to use for running mvn ch.epfl.scala:maven-bloop_2.10:<bloop_version>:bloopInstall. By default, Metals uses an embedded mvnw script. Update this setting if your mvn script requires more customizations.
metals.gradleScript Optional absolute path to a gradle executable to use for running gradle bloopInstall. By default, Metals uses an embedded gradlew script. Update this setting if your gradle script requires more customizations.
metals.scalafmtConfigPath Optional custom path to the .scalafmt.conf file. Should be an absolute path and use forward slashes / for file separators (even on Windows).
metals.scalafixConfigPath Optional custom path to the .scalafix.conf file. Should be an absolute path and use forward slashes / for file separators (even on Windows).
metals.customRepositories Optional list of custom resolvers passed to Coursier when fetching metals dependencies. For documentation on accepted values see the Coursier documentation. The extension will pass these to Coursier using the COURSIER_REPOSITORIES environment variable after joining the custom repositories with a pipe character (
metals.bloopVersion This version will be used for the Bloop build tool plugin, for any supported build tool,while importing in Metals as well as for running the embedded server
metals.bloopSbtAlreadyInstalled If true, Metals will not generate a project/metals.sbt file under the assumption that sbt-bloop is already manually installed in the sbt build. Build import will fail with a 'not valid command bloopInstall' error in case Bloop is not manually installed in the build when using this option.
metals.statusBarEnabled Turn on usage of the statusBar integration. Note: You need to ensure you are adding something like %{coc#status()} in order to display it, or use a plugin that includes a status integration.
metals.superMethodLensesEnabled Enable/disable goto super method code lens (default is true)
metals.enableStripMarginOnTypeFormatting When enabled, if you press the return key from the first line of a multiline string containing a pipe, it will automatically add .stripMargin. (default is true)
metals.excludedPackages List of packages you'd like to be left out of completions, symbol searches, and code actions. Ex. akka.actor.typed.javadsl will ensure nothing in the javadsl package gets recommended to you. You can find the list of default exclusions here on the Metals website. If you need to remove one of the defaults, you can simply include it and preface it with --.
metals.showInferredType When this option is enabled, each method that has infered types have those types displayed as extra info in the hover window.
metals.showImplicitArguments When this option is enabled, each method that has implicit arguments have those aruments displayed as extra info in the hover window.
metals.showImplicitConversionsAndClasses When this option is enabled, each implicit method and class is displayed as extra info in the hover window.
metals.treeviews.toggleNode Expand / Collapse tree node (default <CR>)
metals.treeviews.initialWidth Initial Tree Views panels (default 40)
metals.treeviews.initialViews Initial views that the Tree View Panel Displays. Don't mess with this unless you know what you're doing.
metals.treeviews.gotoLastChild Go to the last child Node (defalt J)
metals.treeviews.gotoParentNode Go to parent Node (default p)
metals.treeviews.gotoFirstChild Go to first child Node (default K)
metals.treeviews.executeCommand Execute command for node (default r)
metals.treeviews.gotoPrevSibling Go to prev sibling (default <C-k>)
metals.treeviews.gotoNextSibling Go to next sibling (default <C-j>)
metals.treeviews.forceChildrenReload Force the reloading of the children of this node. May be useful when the wrong result is cached and tree contains invalid data. (default f)
metals.treeviews.executeCommandAndOpenTab Execute command and open node under cursor in tab (if node is class, trait and so on) (default t)
metals.treeviews.executeCommandAndOpenSplit Execute command and open node under cursor in horizontal split (if node is class, trait and so on) (default s)
metals.treeviews.executeCommandAndOpenVSplit Execute command and open node under cursor in horizontal split (if node is class, trait and so on) (default v)

Enable on type formatting for multiline string formatting

on-type

To properly support different multiline string formatting options like adding | in your multiline string we use the onTypeFormatting LSP functionality. To enable the functionality you need to enable coc.preferences.formatOnType setting.

coc-preferences-formatOnType

Shut down the language server

The Metals server is shutdown when you exit vim as you normally would.

:wq

This step clean ups resources that are used by the server.

Statusline integration

It's recommended to use a statusline integration with coc-metals in order to allow messages to be displayed in your status line rather than as a message. This will allow for a better experience as you can continue to get status information while entering a command or responding to a prompt. However, we realize that not everyone by default will have this setup, and since the user needs to see messages about the status of their build, the following is defaulted to false.

"metals.statusBarEnabled": true

Again, it's recommended to make this active, and use a statusline plugin, or manually add the coc status information into your statusline. coc.nvim has multiple ways to integrate with various statusline plugins. You can find instructions for each of them located here. If you're unsure of what to use, vim-airline is a great minimal choice that will work out of the box.

With vim-airline, you'll notice two noteworthy things. The first will be that you'll have diagnostic information on the far right of your screen.

Diagnostic statusline

You'll also have metals status information in your status bar.

Status bar info

Without a statusline integration, you'll get messages like you see below.

No status line

If you don't use a statusline plugin, but would still like to see this information, the easiest way is to make sure you have the following in your .vimrc.

set statusline^=%{coc#status()}%{get(b:,'coc_current_function','')}

Formatting on save

If you'd like to have :w format using Metals + Scalafmt, then make sure you have the following in your :CocConfig.

"coc.preferences.formatOnSaveFiletypes": ["scala"]

Analyzing Stacktraces

analyze-stacktrace

NOTE: Only available in Neovim since this needs virtual text.

To utilize the analyze stacktrace command you'll want to copy your your stacktrace to your register. Once copied, simply execute the metals.analyze-stacktrace command. This should create a .metals/stacktrace.scala file which will have code lenses which will allow you to jump to the part of your codebase listed in the stacktrace. Keep in mind that in order to utilize this feature you'll want to make sure you have "codeLens.enable": true in your config.

Debugging

coc-metals provides easy integration with the great vimspector plugin that allows you to run a Debug Adapter Server and debug your application with minimum manual steps.

Requirements:

  • *This is only currently available for Neovim +0.4.3 for now until the the launch.json Metals expects can be mapped to match the .vimspector.json file that vimspector uses. For now, you'll need to trigger the run or debug with code lenses provided by Neovim.

  • vimspector plugin - Basically you just need to add vimspector into vim's runtimepath, for example, if you are using vim-plug then add this line in .vimrc

Plug 'puremourning/vimspector'

Configuration:

The vimspector documentation is quite robust, so please make sure to read through it.

There are multiple ways to have you base configuration for vimspector to work with Metals. You can either set this up globally to work with all of your Scala projects or for an individual project.

Global Example:

Put your coc-metals.json file in the following directory: /path/to/vimspector/configurations/{os}/scala (where os is linux, macos or windows) with following content:

{
  "configurations": {
    "coc-metals": {
      "adapter": {
        "port": "${port}",
        "variables": {
        }
      },
      "configuration": {
        "request": "launch"
      },
      "breakpoints": {
        "exception": {
          "caught": "N",
          "uncaught": "N"
        }
      }
    }
  }
}

You can also just place the same contents above in the root of your local project in a .vimspector.json file, and it will work the same way.

With these configuration parameters the codeLens 'run' and 'debug' appear against runnable classes (applications or tests) of your project. Then, you will be able to trigger these codeLens actions (default mapping is <leader> cl) and start Debug Adapter Server. Once Debug Adapter Server is started coc-metals will transfer necessary information to vimspector to activate debugging.

For now both actions 'run' and 'debug' start vimspector in debug mode. This may be improved in next versions.

Gitignore

The Metals server places logs and other files in the .metals/ directory. The Bloop compile server places logs and compilation artifacts in the .bloop directory. A Bloop plugin that generates Bloop configuration is added in the project/metals.sbt file. If you are editing Ammonite scripts, you'll also see an .ammonite directory created for Ammonite. It's recommended to ignore these directories and file from version control systems like git.

# ~/.gitignore
.metals/
.bloop/
project/metals.sbt
.ammonite/

Troubleshooting

If you have any questions or issues with coc-metals, please submit an issue in this repo if it pertains to the extension. If the issues is general to Metals, please submit it in the Metals issue repo. If you have any feature requests, we also have a feature request issue repo. There is also a section in the wiki for Commonly Asked Questions. Fee free to peruse that to potentially find an answer you may be looking for.

Contributing

If you're interested in contributing, please visit the CONTRIBUTING guide for help on getting started.

Theme

The screen shots are in Neovim. The theme is onedark. The status bar is vim-airline, and all being ran in iTerm2.

coc-metals's People

Contributors

ajkaanbal avatar amiralies avatar ckipp01 avatar danilbykov avatar dependabot-preview[bot] avatar dependabot[bot] avatar gabro avatar greenkeeper[bot] avatar gridbugs avatar jqno avatar jsatk avatar mpasa avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

coc-metals's Issues

Renaming public members doesn't work in Vim

Describe the bug
When I use the rename command on a public symbol, such as a class or a method, the references are updated only in the current file, and not across the project. This happens only if I use vim. I also tried with VSCode, and it seems to work fine in that case; I noticed that when renaming, all the files with references get opened and modified; I don't see the equivalent of this happening in Vim.

Note that I am new to metals.

To Reproduce
Steps to reproduce the behavior:

  1. Open a scala project in vim.
  2. Open a file with a public class that is references elsewhere in the codebase.
  3. Move the cursor on the class name, and use the rename action; in my case, I am pressing <Space> c to bring up all the commands, and choose the document.renameCurrentWord command.
  4. Go to insert mode and edit the class name. If the class is also references in the current file, note that the references get updated automatically.
  5. Compile the project, and notice that it doesn't compile because the references in other files weren't updated.

Note that the reason why I am bringing up the list of commands above is that the direct keybinding for the rename doesn't seem work for me:

" Remap for rename current word
nmap <leader>rn <Plug>(coc-rename)

When I press <Space> rn, then it's as if it wasn't recognized at all (and the rn command replaces the character under the cursor with n). Most other keybindings involving space work, though.

Expected behavior
When renaming a public symbol, all references in all files should be updated, and not just the ones in the current file. I'd like this to work in vim as well, and not just in Visual Studio Code.

Installation:

  • Operating system: Arch Linux
  • Editor: NVIM v0.4.3
  • Metals version: v0.8.4

I followed the vim installation guide. I am using the coc.nvim plugin, and used the suggested configuration as is.

Odd highlighting in float with long text

Describe the bug

EDIT: See the original context below, but I'm actually unsure now what is causing this. I'll have to try and get more reproductions in order to chase this down.

In a worksheet, if you do a hover in Neovim and check the filetype in the window, it's set to nothing.

To Reproduce Steps to reproduce the behavior:

  1. Create worksheet
  2. Evaluate and hover
  3. set ft?
  4. See that it's set to nothing

Expected behavior

This should be set to scala, which will help with syntax highlighting

Screenshots

Screenshot 2020-01-16 at 11 41 20

Installation:

  • Operating system: macOS
  • Vim or nvim version: Nightly 5
  • coc-metals extension version: Latest
  • Metals version: Latest

Additional context

hover windows, worksheets

Search terms

Add in gradle to activationEvents

Describe the bug

The activationEvents key is missing worksapceContains:build.gradle, which is causing metals to not start when expected for gradle builds.

Search terms

gradle, activationEvents

Integration with vimspector

Describe the feature

This vim plugin (puremourning/vimspector) implements DebugAdapterProtocol which was recently added in metals. At this moment it supports several languages (C, Java, Python, javascript and so on). Are you interested in integration between coc-metals and vimspector?

Potential ways to implement?

In order to start debug session in vimspector, user should define file .vimspector.json. This file describes how to start Debug Server, path to program, environment variables and so on. In scala we don't need these options because metals can start Debug Server for us. So we don't need whole file .vimspector.json. Vimspector should just connect to this server and start talking. I'm going to open Pull Request for vimspector and implement this.

So general flow is

  1. Using CodeLens from LSP we start DebugAdapter in Metals
  2. Metals returns port where DebugAdapter is started
  3. coc-metals calls vimspector and provides this port.

I was able to debug simple test application using this schema.

Additional context

vimspector is enough buggy plugin but hopefully they will be able to polish it.

Feature request: Add ability to disable language server autoloading

Related to neoclide/coc.nvim#1759

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

I'm always frustrated when configured language server loads, I'd like to have more control and start services explicitly when I need them.

Describe the solution you'd like

An enable flag support for metals language server:

"metals.enable": false,

Describe alternatives you've considered

:CocUninstall coc-metals

How to run bloop tests?

Question

Is there a way to run something like :!bloop test project from Vim to reuse already compiled classes?

Installation:

  • Operating system: Linux
  • Vim version: 8.1.1486
  • coc.nvim version: 0.0.77-817efd5108
  • coc-metals extension version: 0.8.0
  • Metals version: 0.8.4+62-67ef4e74-SNAPSHOT

Search terms

bloop test

bloopInstall runs every time, always prompted about Scala version even after choosing Don't Ask Again

Question

  1. Every time I open neovim in our project, it imports build and runs bloopInstall again. We do not use sbt-bloop in our project.

  2. Every time I open neovim, it always reminds me about the Scala version being older. If I choose Don't ask again, it doesn't remember the next time.

I updated recently, I feel like I may have something misconfigured since that upgrade that coc-metals isn't able to see the last build, my "dont ask again" preferences, and so on. Looking through google and the docs, I haven't found what it might be. Or perhaps this is normal.

Commented out line keeps virtual text in worksheets

Describe the bug

When you're in a worksheet and you comment out a line and then save, the virtual text still remains.

To Reproduce Steps to reproduce the behavior:

  1. Create a worksheet
  2. Evaluate worksheet
  3. Comment out a line and re-save
  4. See that the virtual text still remains

Expected behavior

I'd expect this behavior to be the same as that in VS Code so that when you comment out a line and save, it removes the virtual text for that line.

Screenshots

Screenshot 2020-01-11 at 18 40 03

Installation:

  • Operating system: macOS
  • Vim or nvim version: Nvim Nightly
  • coc-metals extension version: 0.5.1
  • Metals version: Latest Snapshot

Search terms

Neovim, worksheets, virtual text

vim+metals opening a symbol in tvp opens in nerdtree

Describe the bug

vim+metals opening a symbol in tvp opens in nerdtree

To Reproduce Steps to reproduce the behavior:

  1. open nerd tree left of the editor
  2. open tvp view (opens left of the nerd tree)
  3. find a symbol in tvp and click r to open it

Expected behavior

the symbol / file would be opened in the editor on the right

Screenshots

The middle window was NERDTree before r was pressed on the lower-left side window:

2020-04-17-182807_3828x2069

Installation:

  • Operating system: Linux
  • Vim or nvim version: NVIM v0.4.3
  • coc-metals extension version: 8a12eec
  • Metals version: "0.8.4"

Additional context

Search terms

tvp, NerdTree

TreeView opens when typing "-" in netrw

Describe the bug

TreeView opens when typing "-" in netrw. Not every time, around 50% of cases. FWIW I don't have NerdTree plugin installed.

To Reproduce Steps to reproduce the behavior:

  1. Open netrw.
  2. Type "-".
  3. See TreeView windows(3) open.

Expected behavior

Not to open TreeView.

Installation:

  • Operating system: macOS
  • Vim or nvim version: 0.4.6
  • coc.nvim version: 0.0.78-d6dd56bba8
  • coc-metals extension version: 0.8.3
  • Metals version: 0.9.0

Action required: Greenkeeper could not be activated 🚨

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

Ensure package.json is getting updated on release

Task

Currently the version is being tagged and correctly set when publishing, but we aren't updating the package.json. Ensure that this happens on release.

This is important because if people are using the url to install, and then they try to list their extensions in coc, it will show the old version in the package.json, not the tagged version.

Hover in worksheet expansion showing markdown

Describe the bug

When using worksheets and neovim and you expand the hoverMessage you see the following:

Screenshot 2020-06-12 at 11 09 02

Something changed recently which is now causing the markdown to be seen in the hover.

Expected behavior

The markdown should be rendered and not shown.

Search terms
worksheets, neovim

Installation under FreeBSD

The plugin does not install under FreeBSD.

Steps to reproduce the behavior:

Either use :CocInstall coc-metals or the Vim-Plug installation and do a :PlugInstall.

There are two different errors here but I guess below the hood they might be the same.

Error message from CocInstall

There is just a red status line saying:

[coc.nvim] Error on install coc-metals: Error: EPERM: operation not permitted, unlink '/tmp/coc-metals-s4W6ca'

Error message from PlugInstall

There are some message but they scroll through too fast and in the end the status line says:

[coc-nvim] extension "coc-metals" doesn't contain main file ~/.config/nvim/bundle/coc-metals/lib/index.js.

Expected behavior

The plugin should install or provide an alternate way to install it which works.

Installation:

  • Operating system: FreeBSD 12.1
  • Vim or nvim version: 0.4.3
  • coc.nvim version: latest stable
  • coc-metals extension version: latest stable
  • Metals version: 0.9.0

Notes

This happened today as I was updating my plugins and metals. Until now I used only coc.nvim without the coc-metals script (using the coursier bootstrap installation which seems to be gone from documentation now). I wouldn't mind the plugin but as it seems it doesn't work without it anymore. :-(

Running something like CocRequestAsync('metals', 'workspace/executeCommand', { 'command': 'build-import' }) manually yields in an error message `Language server metals not found'

Companion object apply signature

Does this support showing the function signature for a CompanionObject.apply?

I can't seem to get that working, however I can get function signatures to display for standard functions, so I don't think I need to change configurations or anything.

Fix release drafter

Something seems to be going wrong with the release drafter. It's grabbing a whole bunch of commits from the past and displaying them for each release. I mimicked the way we do this with the vs code extension, but for some reason it's working very differently.

Persisted Errors even after compiling

Describe the bug
I am using sbt 0.13 and scala 2.11 so not sure if it's related to that but...
When I write an error it persists until I physically :e % the file. Then the "gutter" error will go away. Then if I add a comment or delete some white space the error shows up again so I :w the file error is still there then :e % and the gutter errors disappear. I'm using nvim and I updated coc last night.

Shifted lines leaving behind virtual text

Describe the bug

If you are in a worksheet in Neovim and evaluate, then go to the beginning of the evaluated line, shift everything down a line, you'll see that the virtual text isn't cleared correctly.

To Reproduce Steps to reproduce the behavior:

  1. Create a worksheet
  2. Evaluate worksheet
  3. Go to the beginning of the line for evaluated worksheet and hit enter
  4. See error

Expected behavior

This should shift the virtual text along with the line.

Screenshots

Screenshot 2020-01-15 at 11 27 35

Installation:

  • Operating system: macOS
  • Vim or nvim version: Nvim 5
  • coc-metals extension version: Latest

Search terms

virtual text, worksheets

Action required: Greenkeeper could not be activated 🚨

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

`root_patterns` not correctly being recognized

Describe the bug

I have a workspace which has the following structure:

  root
  |- projects
  |   |- project1
  |      - src/scala/some.scala
  |      - build.sbt
  - build.sbt

When I use vim to open the some.scala, the plugin uses projects/project1 as the workspace folder and creates .metals under projects/project1. But it causes library loading failure due to the common settings that are specified in the root/build.sbt.

VSCode open the project correctly and generate .metals directory under root directory.

Expected behavior

Open root as the workspace.

Installation:

  • Operating system: macOS
  • Vim or nvim version: NVIM v0.4.3
  • coc.nvim version:0.0.78-0c973a7a47
  • coc-metals extension version:
  • Metals version: (:CocConfig to open settings)

New stripMargin `onTypeFormatting` not working as expected

Describe the bug

When using the latest snapshot of Metals and attempting to use the new stripMargi onTypeFormatting, the edits are applied correctly, but the cursor seems to end up in the wrong position. See the gif below:

2020-06-01 12 43 00

To Reproduce Steps to reproduce the behavior:

  1. Use latest snapshot
  2. Make sure coc.preferences.formatOnType is set to true
  3. Go into a multiline string that doesn't have a .stripMargin and hit enter after the pipe.
  4. See error

Expected behavior

That the edits be applied and the cursor ends up in the right position just like it does in VS Code.

Here is how it works in VS Code:

2020-06-01 12 56 43

Additional context

Created an issue for this here: neoclide/coc.nvim#2015 since it seems to be an issue with coc.

Search terms

onTypeFormatting

Improve the opening of the TVP panel with NERDTree

Task

If you look at the image inside of #169 you'll notice that since NERDTree was opened, for some reason the TVP panel opens up almost half the width of the screen. Ideally we wouldn't want that. This however doesn't happen with the TVP panel is on the opposite side of NERDTree.

Additional context

NERDtree

Search terms

TVP, NERDTree

UnhandledRejection: Cannot read property 'reader' of undefined

Describe the bug

[coc.nvim] error: UnhandledRejection: Cannot read property 'reader' of undefined
TypeError: Cannot read property 'reader' of undefined
    at C:\Users\Oliver\.nvim\plugged\coc.nvim\build\index.js:57558:48

when preparing metals.

Using :CocInstall coc-metals to install coc-metals. The above error occurs when metals is being prepared.

Installation:

  • Operating system: Windows
  • nvim 0.4.3

Translate readme to Japanese

Describe the feature

From looking at the regions of the world via google analytics on the metals website and tracking references on blogs/twitter, it seems that Japan has the second largest usage of both metals and coc-metals. I'd be great to have a Japanese translation to the readme in order to help anyone out that may need it.

Search terms

Japanese

Update notification disappears shortly after display

Describe the bug

When I start vim I get a short time flash of "You are running an out-of-date version of Metals…" and then it disappears with cursor still blocked awaiting for user input. Sometimes it reappears, sometimes not.

notification

Expected behavior

Notification doesn't disappear until input provided.

Installation:

  • Operating system: Linux
  • Vim version:
    $ vim --version
    VIM - Vi IMproved 8.1 (2018 May 18, compiled Mar  4 2020 10:55:18)
    Included patches: 1-1486
    
  • coc-metals extension version: 0.7.4
  • Metals version:
     "metals.serverVersion": "0.8.1+19-04f10d20-SNAPSHOT"
    

Search terms

update notification disappear

TreeViewProtocol support

I have implemented basic support for TreeViewProtocol. It is far from completion for now but at least trees are loaded and rendered in vim. I'm going to implement more hotkeys, configuration settings, better buffer management and so on.

If you want, I can port my changes into your repository.

Show the scaladoc in the preview floating window while auto-completion

Hi.

First thank you for the great coc extension.

What I'm still missing is the display of the scaladoc of the selected
method while cycling through the suggestions of the auto-completion.

I would love to read the scaladoc of the given method directly
in the preview floating window below the method signature.

The coc-rls (for the Rust) shows beautiful how it can work well.

What do you think?

Metals does not recognise build.sbt / sets wrong directory as workspace

For some reason, coc-metals won't run correctly in my scala project. I have demonstrated that there is nothing wrong with the project itself by duplicating the project in a different directory and demonstrating coc-metals to work fine with it. I've also used unix diff to make sure that the two projects are identical (with the exception of some reasonable differences to metals.log and metals.lock.db).

Initially, during my debugging, I discovered that the versions of sbt and scala that I was running were too old and these were probably the original cause of my troubles, however my original project still does not work with coc-metals in the following manner:

From within my project root (which I'm calling /path/to/myproject), running vim build.sbt produces no behaviour from coc whatsoever.

I can get coc to try and run metals if I open a scala file (e.g. vim /path/to/myproject/src/main/main.scala). In this case, coc-metals gets confused about where the project root is. Instead of creating a .metals directory in /path/to/myproject (where my build.sbt is located), it instead puts it in the directory above, /path/to. it does not try to import the build. It simply stops with a message:

no build target for:/path/to/myproject/src/main/main.scala

This message can be found in the log file located at /path/to/.metals/metals.log. The complete log is reproduced below:

INFO started: Metals version 0.8.0 in workspace '/path/to'
INFO time: initialize in 2.25s
WARN no build tool detected in workspace '/path/to'. The most common cause for this problem is that the editor was opened in the wrong working directory, for example if you use sbt then the workspace directory should contain build.sbt.
WARN no build target for: /path/to/myproject/src/main/main.scala

I've tried cleaning the project by deleting, target/, project/target, project/project/target, and ../.metals, but this has not helped. I've also tried uninstalling and reinstalling coc and coc-metals. I've tried running sbt reload.

I've also tried copying the .metals and .bloop directories from my working version of the project to the original, but they seem to be ignored.

I've also tried turning around, touching the ground, and drinking 3 bloody marys.

The only thing I can imagine is that coc-metals has somehow cached my original workspace directory and refuses to let go of it. Any help getting to the bottom of this would be appreciated

add bloop version to coc-settings

Describe the feature
I would like to be able to set the version of bloop via the coc-seetings

Potential ways to implement?

add a bloopVersion json key

Additional context

the metals.sbt file that is auto generated keeps generating

// DO NOT EDIT! This file is auto-generated.
// This file enables sbt-bloop to create bloop config files.

addSbtPlugin("ch.epfl.scala" % "sbt-bloop" % "1.4.0-RC1")

so i had to add the bloop plugin to my plugins.sbt with the snapshot version
addSbtPlugin("ch.epfl.scala" % "sbt-bloop" % "1.4.0-RC1-64-96c8b667")

Search terms

from bench/it:bloopCompile ((bloop.integrations.sbt.Offloader) Offloader.scala:19)

Cannot find module 'metals-languageclient'

When I open any scala file I get the error:
[coc.nvim] Error on load extension coc-metals from /home/user/.config/coc/extensions/node_modules/coc-metals/lib/index.js: Error: Cannot find module 'metals-languageclient'

To Reproduce Steps to reproduce the behavior:

  1. Go to scala project folder
  2. Run 'nvim .'
  3. Open any scala file
  4. See error

Installation:

  • Operating system: Linux (LUbuntu 18.04 LTS)
  • nvim version: v0.5.0
  • coc-metals extension version: 0.7.2
  • node version: v8.10.0

node 14 is not supported

Describe the bug

node v14 build breaks:

# yarn install --frozen-lockfile  
yarn install v1.22.4
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
[1/5] Validating package.json...
warning [email protected]: The engine "coc" appears to be invalid.
[2/5] Resolving packages...
[3/5] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[4/5] Linking dependencies...
[5/5] Building fresh packages...
$ npx npm-run-all clean build
yarn run v1.22.4
warning [email protected]: The engine "coc" appears to be invalid.
$ rimraf lib
Done in 0.13s.
yarn run v1.22.4
warning [email protected]: The engine "coc" appears to be invalid.
$ tsc --noEmit && parcel build src/index.ts --out-dir lib/ --target node --no-source-maps
(node:19710) UnhandledPromiseRejectionWarning: Error: Could not locate the bindings file. Tried:
 → /home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/deasync/build/deasync.node
 → /home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/deasync/build/Debug/deasync.node
 → /home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/deasync/build/Release/deasync.node
 → /home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/deasync/out/Debug/deasync.node
 → /home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/deasync/Debug/deasync.node
 → /home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/deasync/out/Release/deasync.node
 → /home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/deasync/Release/deasync.node
 → /home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/deasync/build/default/deasync.node
 → /home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/deasync/compiled/14.1.0/linux/x64/deasync.node
 → /home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/deasync/addon-build/release/install-root/deasync.node
 → /home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/deasync/addon-build/debug/install-root/deasync.node
 → /home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/deasync/addon-build/default/install-root/deasync.node
 → /home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/deasync/lib/binding/node-v83-linux-x64/deasync.node
    at bindings (/home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/bindings/bindings.js:126:9)
    at Object.<anonymous> (/home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/deasync/index.js:30:31)
    at Module._compile (/home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/v8-compile-cache/v8-compile-cache.js:194:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1196:10)
    at Module.load (internal/modules/cjs/loader.js:1040:32)
    at Function.Module._load (internal/modules/cjs/loader.js:929:14)
    at Module.require (internal/modules/cjs/loader.js:1080:19)
    at require (/home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/v8-compile-cache/v8-compile-cache.js:161:20)
    at Object.<anonymous> (/home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/parcel-bundler/src/utils/syncPromise.js:1:79)
    at Module._compile (/home/sarunas/.local/share/nvim/plugged/coc-metals/node_modules/v8-compile-cache/v8-compile-cache.js:194:30)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:19710) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:19710) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Done in 1.92s.
Done in 5.86s.

coc-metals - 7b959dc

Account for upstream TVP changes for compilations view to work

Describe the feature

There has recently been work done on the Metals side to change a bit of the way Tree Views work: scalameta/metals#1677. It's quite a small change on the Metals side, but it breaks the current implementation of the TVP panel in coc-metals. The main issue seems to be now that the metalsCompile returns no nodes when there are no compilations going on. In the current implementation, we count on that.

Potential ways to implement?

From what I can tell, the logic here needs to change:

let ev: TreeModelUpdate;
if (initEvent.root.underlying.nodeUri === undefined) {
ev = {
root: initEvent.newNodes[1],
oldNodes: initEvent.oldNodes.slice(1),
newNodes: initEvent.newNodes.slice(1),
focusEvent: initEvent.focusEvent,
};
} else {
ev = initEvent;
}

I've played around with this a bit, but I keep getting to a position where I get the compilations to appear, but can't correctly clear them.

Additional context

I'm assuming this is a small change that needs to happen, but an understanding of how this is implemented is probably important. Tagging @danilbykov since they were the author of it and may have a much better idea that I do.

For the time being, I've disabled this view in #190 and replaced it with the new version of metalsBuild.

The metalsCompile will need to be added into the metals.treeviews.initialViews object in the package.json in order to work.

I don't currently have the capacity to spend a bunch of time on this, and don't personally ever use this compilations view. If someone wants to tackle this, it'd be extremely appreciated.

Search terms

Treeview panel

Create status bar integration

Currently, status bar items aren't enabled because we can't ensure that every user has a statusline integration. It's much nicer to display stuff there, so in the future, I think we could build in a setting that a user can turn in saying they want to use a statusbar integration, and if so, then display that information there.

Improve the TVP Panel

Decision

I'm not going to migrate. Ultimately Vista serves a different purpose as a symbol explorer for the current document. It does look quite nice imo, and I'm going to try to spruce up the TVP panel to be a bit more polished.

Question

We currently have a built-in version of the Tree View Protocol. This works well enough, but it's definitely not polished. There are also some issues when working with other plugins like NerdTree. See #169 as an example. There have been some talks about one being built-in to coc.nvim to support call hierarchies, but vista exists and works wonderfully.

I think some initial work should go into exploring how doable it would be to just replace the TVP module in coc-metals and delegate all of the TVP related stuff to Vista if it's doable. This may result in a much more polished experience.

My goal of this is to hopefully get some feedback from users and take some notes about things I notice as I explore this.

Screenshots

Screenshot 2020-04-18 at 11 26 06

Things to consider

  • The image above shows this without custom integration at all, it's just using the built-in coc symbol explorer for the current file. We'd need to figure out how this might work for an entire tree view of not just the current file, but the entire tree.

  • In the current panel there are a few things like ongoing compilations and some commands like Cascade compile etc. Are these features used at all by coc-metals users?

  • Can Vista allow you to explore external dependencies?

Things I like

  • As the image shows up, just in general, it's much more polished.

  • Currently with the built-in TVP, you can see symbols in a build.sbt file for example. Without any work, this works great with Vista.

Screenshot 2020-04-18 at 11 45 29

  • I like that you're able to get a preview of the symbol in the sidebar

Screenshot 2020-04-18 at 12 17 25

Blockers

The biggest blocker is that it doesn't fully implement the Tree View Protocol since it's not meant to. if we did switch to this we'd be missing a huge amount of features that I don't think we can give up. The route that I'm leaning now is to significantly improve the appearance of the TVP panel to mimic the way Vista looks.

Search terms

TVP, Vista

Allow for integration with vimspector to work with Vim

Task

We currently have an artificial limitation that vim users can't use vimspector with coc-metals due to code lenses. While that used to be true, but that's not the case anymore. I believe we need to just provide examples for what to put in the .vimspector.json file, and then it should work since Metals can handle things coming in from a launch.json file.

Additional context

This is a follow-up to #83

You can find more information on the launch.json here.

Search terms
dap, debugger, vim

Setting `metals.javaHome` causes CoC to exits abnormally

Describe the bug

When prompted to add a metals.javaHome after opening a tmp Scala file it exits "abnormally" with status code of -1.

Example of what's in my coc-settings.json:

  "metals.javaHome": "/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/"

To Reproduce Steps to reproduce the behavior:

  1. vim /tmp/foo.scala
  2. Notice prompt about Java Home not being configured.
  3. Press 1 to open coc-settings.json.
  4. In a shell run echo $JAVA_HOME | pbcopy # macOS required for pbcopy. Otherwise just copy the printed path
  5. Paste clipboard into metals.javaHome in coc-settings.json.
  6. Get reload prompt.
  7. Press 1 to reload.
  8. Experience error.

Expected behavior

  1. vim /tmp/foo.scala
  2. Notice prompt about Java Home not being configured.
  3. Press 1 to open coc-settings.json.
  4. In a shell run echo $JAVA_HOME | pbcopy # macOS required for pbcopy. Otherwise just copy the printed path
  5. Paste clipboard into metals.javaHome in coc-settings.json.
  6. Get reload prompt.
  7. Press 1 to reload.
  8. No error and everything works well.

Installation:

  • Operating system: macOS
  • Vim 8
  • coc-metals extension version: The latest
  • Metals version: 0.8

Search terms

java_home, javaHome

Make example statusline settings for various integrations

Task

I currently have a general message about the statusline integration in the readme, but it would be nice to have more detailed examples in the wiki for the various plugins to get people to where they need to go more quickly to enable the statusline integration.

Search terms

statusline

Buffer wiped out from search results

Describe the bug

This happens for find references and jump to definitions when there are multiple search results.

  1. Open a file (Foo.scala) and go to find references inside the project ( make sure there are multiple references)
  2. The windows change sizes and my current buffer (Foo.scala) is loaded with the search results from the plugin.
  3. Foo.scala is set to unmodifable.
  4. Select a search result.
  5. buffer Foo.scala is blow away and all of my changes to Foo.scala are lost.

This is a pretty serious bug seems like it might be coming from the coc plugin but i'm not sure.

Installation:

  • macOS
  • nvim latest
  • coc-metals extension version:
  • Metals version: 0.8.0+313-40759eb6-SNAPSHOT
  • scala 2.11
  • sbt 0.13

Unable to install using `:CocInstall` with the GitHub url

Describe the bug

It used to work (and should work) to be able to do a :CocInstall https://github.com/scalameta/coc-metals. However, when you do this now, you are greeted with the following.

[coc.nvim] error: /Users/ckipp/bin/npm install exited with 1, messages:
npm WARN deprecated [email protected]: Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to us
e Promises in 1.x.)
npm WARN deprecated [email protected]: core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your depende
ncies to the actual version of core-js@3.
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
No receipt for 'com.apple.pkg.CLTools_Executables' found at '/'.
No receipt for 'com.apple.pkg.DeveloperToolsCLILeo' found at '/'.
No receipt for 'com.apple.pkg.DeveloperToolsCLI' found at '/'.
gyp: No Xcode or CLT version detected!
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/Users/ckipp/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:351:16)
gyp ERR! stack     at ChildProcess.emit (events.js:210:5)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:272:12)
gyp ERR! System Darwin 19.4.0
gyp ERR! command "/Users/ckipp/bin/node" "/Users/ckipp/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /private/var/folders/fq/nx_jsnyd6550xp03czx898d40000gn/T/coc-metals-4ei7YE/node_modules/fsevents
gyp ERR! node -v v12.13.1
gyp ERR! node-gyp -v v5.0.5
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: `tsc --noEmit && parcel build src/index.ts --out-dir lib/ --target node --no-source-maps`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/ckipp/.npm/_logs/2020-04-02T14_20_45_167Z-debug.log
ERROR: "build" exited with 1.
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] prepare: `npx npm-run-all clean build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] prepare script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/ckipp/.npm/_logs/2020-04-02T14_20_45_228Z-debug.log

To Reproduce Steps to reproduce the behavior:

  1. :CocInstall https://github.com/scalameta/coc-metals

Expected behavior

This should correctly install the plugin

Installation:

  • Operating system: macOS
  • Vim or nvim version: Nvim latest

Search terms
CocInstall

Create new symbol code action not working

Describe the bug

When you try to use the new create new symbol code action in the latest metals snapshot, you correctly get the code action, but for some reason the quick pick isn't being shown to the user and we are just responding with nothing.

To Reproduce Steps to reproduce the behavior:

  1. Create something that doesn't exist like val x = new Test(3)
  2. Trigger the code action on Test which doesn't exist to create the new symbol.
  3. Click 1 to say that's the code action you'd like.
  4. Nothing happens.

Expected behavior

I'd expect the quickpick to appear.

Additional context

lsp trace

[Trace - 10:35:35 AM] Sending response 'textDocument/codeAction - (29)'. Processing request took 8ms
Result: [
  {
    "title": "Create new symbol \u0027Test\u0027...",
    "kind": "quickfix",
    "diagnostics": [
      {
        "range": {
          "start": {
            "line": 5,
            "character": 11
          },
          "end": {
            "line": 5,
            "character": 15
          }
        },
        "severity": 1,
        "source": "bloop",
        "message": "not found: value Test"
      }
    ],
    "command": {
      "title": "Create new scala file",
      "command": "new-scala-file",
      "arguments": [
        null,
        "Test"
      ]
    }
  }
]


[Trace - 10:35:36 AM] Received request 'workspace/executeCommand - (30)'
Params: {
  "command": "new-scala-file",
  "arguments": [
    null,
    "Test"
  ]
}


[Trace - 10:35:36 AM] Sending request 'metals/quickPick - (6)'
Params: {
  "items": [
    {
      "id": "class",
      "label": "Class"
    },
    {
      "id": "case-class",
      "label": "Case class"
    },
    {
      "id": "object",
      "label": "Object"
    },
    {
      "id": "trait",
      "label": "Trait"
    },
    {
      "id": "package-object",
      "label": "Package Object"
    },
    {
      "id": "worksheet",
      "label": "Worksheet"
    }
  ],
  "placeHolder": "Select the kind of file to create"
}


[Trace - 10:35:36 AM] Received response 'metals/quickPick - (6)' in 0ms
Result: null

Search terms

code action, quickpick

Mixing coc-metals and coc-java

Question

I have coc-java and coc-metals installed. We use Maven at work for our Scala projects. Whenever I open a Scala file or a Java file, both language servers seem to activate and start building stuff.

Is there a way to prevent coc-metals from running when I'm working on a Java project (and/or coc-java when I'm working on a Scala project)? I think a simple filetype check would suffice for me, I don't work on any mixed projects.

Installation:

  • Operating system: macOS
  • Vim version: 8.1.2400
  • coc-metals extension version: 0.8.0
  • Metals version: 0.8.4
  • coc-java extension version: 1.4.9

Search terms

coc-java maven

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.