We're happy to announce the release of Metals v0.9.4, which focuses on
improvements in Scala 3 worksheets, a couple of new features, and a number of
smaller improvements.
Metals is a language server for Scala that works with VS Code, Vim, Emacs,
Sublime Text, Atom and Eclipse. Metals is developed at the
Scala Center and VirtusLab
with the help from Lunatech along with contributors from
the community.
Thanks to kpbochenek, Metals can now help with
navigating stack traces using the new metals.analyze-stacktrace command. The
only thing it needs is the actual stack trace string to be input as a parameter
to the command. This new functionality works differently in various editors.
Visual Studio Code
The only thing users need to do is copy the stack trace and run the
Analyze Stacktrace command from the command palette. This will display a new
web view, where it will be possible for users to navigate the files that are
included in the exception.
coc-metals
With coc-metals, you just need to copy the stacktrace, whether from sbt,
bloop-cli, or somewhere else into your register. Once you have it copied, you
can just execute the metals.analyze-stacktracecommand. This will create
a.metals/stracktrace.scala file which can be used to navigate through your
stacktrace using code lenses. Keep in mind that you'll want to make sure you
have codeLens.enable set to true in your configuration. Also, since this feature
relies on code lenses (virtual text in Nvim), it's only supported in Nvim.
Other editors
To make it work with any other editors users need to run the command manually
with the stacktrace as input, similar to the example above with coc-metals.
The command will generate a new file, .metals/stacktrace.scala, which can be
used to navigate through the stacktrace using code lenses.
Customizable package exclusions
Usually, a number of packages are almost never used by the developers and could
clutter the language server output while being of little benefit to the users.
Metals would exclude those packages from indexing causing them to not be
recommended for completions, symbol searches, and code actions. Previously that
list was set in stone and consisted of a number of prefixes:
This list might work in most cases, but users might also want to customize the
list according to their preferences and domain they are working on. Starting
with this release it is now possible to define additional exclusions as well as
remove some from the default list. This can be done via an additional Metals
user setting:
-- should only be used to remove some of the defaults if they aren't needed
for your project. Thanks to ckipp01 for
contributing this feature!
Miscellaneous
Some of the smaller improvements to Metals include:
New recommended Maven Scala template.
Fix go to source and auto imports in standalone worksheet files.
Fix missing classes from _empty package in tree view.
Add a command to quickly create a new worksheet with a default name.
Beside all the core work on the server itself, there have also been a lot of
great work done in various other Scalameta projects, which Metals relies on.
These projects include mdoc, which powers
worksheets and Scalameta, which powers
all SemanticDB and parsing powered features. Those contributions helped to
unlock and improve Dotty support in Metals. So special thanks to those projects
and contributors.
Contributors
Big thanks to everybody who contributed to this release or reported an issue!
Metals is a language server for Scala that works with VS Code, Vim, Emacs,
Sublime Text, Atom and Eclipse. Metals is developed at the
Scala Center and VirtusLab
with the help from Lunatech along with contributors from
the community.
sbt script support with hover, completions and go to definition.
Scala 3 worksheet support
Scala 0.25.0 and 0.26.0-RC1 support.
Main classes from dependencies can now be run
sbt script support
Thanks to the great work by dos65 Metals now
supports sbt script files as well as build's Scala files. The full list of
currently supported features is available
here.
sbt support is is achived by generating additional metals.sbt file for each
level of sbt's project. For build.sbt we now generate
project/project/metals.sbt, for project/other.sbtproject/project/project/metals.sbt etc. This is needed for the Bloop plugin to
properly generate information in the .bloop configuration files. It's
recommended to gitignore metals.sbt and .bloop anywhere in the file tree.
Scala 3 worksheet support
Finally, it is now possible to run worksheets for Scala 3 starting with version
0.26.0-RC1. To try it out users need to create the worksheet inside of a Scala 3
source directory and then they can be used the same way as with previously
supported worksheets.
This is a great place for anyone to experiment with Scala 3 and see what is
coming around the corner!
Running main classes from dependencies
Previously, users could only run main classes that are defined in the
sourcecode, which made it impossible to run and debug in certain frameworks such
as the Play Framework. Metals now searches the
classpath additionally to find any classes that are defined by the user and not
available in the main sources.
To run any such class a full name needs to be provided via the configuration.
For example in Visual Studio Code this would look like this:
As of this last Metals release, it's now 100% possible to fully configure Metals
without any need to pass in server properties. Depending on your editor of
choice, the process to configure Metals may be completely abstracted away. You
simply click install, wait a bit, and start coding. In this post I'd like to
talk a bit about the progression of how Metals was originally configured fully
with server properties and how it can now be fully configured via the client,
which in LSP terms is
your editor. This can serve both as a guide for those client extension
maintainers out there and also those curious at how Metals correctly works for
all the various editors.
The first configuration
Looking back to the Fall of 2018, you see a giant glimpse of Metals becoming
what it is today when looking at a giant commit by
@olafurpg with the title Implement pretty
basic language server and build
client..
It's a pretty fascinating commit to look at if you're interested in the
beginnings of Metals, but I want to focus in on a specific file that still exists
today, which is the
MetalsServerConfig.scala.
In this file you see the first configuration options that existed for Metals.
You see things like isLogShowMessage to ensure users were correctly getting
status messages instead of everything just going into the logs. (This was also
before
metals/status
existed which is used today for a better status experience in Metals). You also
see other options like isHttpEnabled for Metals to start the Doctor for those
that needed an HTTP client interface, or even an icons setting to ensure
things looked nice and matched your client. At this point, instead of just
having the user specify every one of these when they bootstrapped the server, a
metals.client property was introduced that we could give editors a set of
defaults. Here is an example for the first settings for Vim and Metals using the
vim-lsc plugin:
The property would then be set when the user would bootstrap Metals. This
started out as a manual process for almost all the editors utilizing
Coursier. This still actually remains a
valid way to configure Metals, although not recommended if your client supports
setting InitializationOptions in the
initalize
request. It's also almost the identical process that happens behind the scenes
when client extensions like
metals-vscode,
coc-metals, and
metals-sublime bootstrap the
server for you. For example, here is how you would manually do this:
In the above example, you would then get the defaults specified in
MetalsServerConfig.scala for emacs. Again, when the process is automated
it's very similar, and you can see this if you poke around the
fetchAndLaunchMetals
function in the VS-Code extension. You can see how the path to Coursier is
grabbed, your JAVA_HOME is captured, and how we get some extra
variables/properties to call Metals with.
User configuration
Apart from server properties, it was also necessary for users to be able to
easily change a setting, even while in the editor. For example, we have a
current setting metals.superMethodLensesEnabled which when enabled will
display a code lens that when invoked will either go to the parent class
containing the definition of the method or symbol or display the full method
hierarchy allowing you to choose where to go.
Here is an example of what this looks like in Vim:
This feature is actually turned off by default since in very large code bases
you may experience a lag. So if a user wanted to turn this on, it wouldn't be a
great user experience to have to re-bootstrap the server to enable this feature.
This is where the User Configuration comes into play by being able to change a
configuration value and notify the server via
workspace/didChangeConfiguration.
This can fully happen for most of the user configuration values without any need
to restart the server. You can see the first configuration options added this
way in this
commit
where the ability to define your JAVA_HOME was added. With now allowing for
user configurations in Metals, this allowed for an even more customized
experience.
Experimental
Being able to customize the server with properties and allowing users to pass in
some configuration values worked great. However, once Metals started creating
LSP extensions for functionality that wasn't supported fully just by LSP, then a
way was needed for the client to express that it supported these extensions.
This is when Metals started to use the
ClientCapabilities.experimental
field which the client needed to declare support the extension. You can see the
first inklings of this when the Tree View
Protocol was
introduced here in this
commit.
This then continued to be further expanded as we introduced more extensions.
As it became easier for various clients to set this, we slowly started to
migrate other options that could
only be previously set via server properties to
ClientCapabilities.experimental. So settings like which format you'd like the
Doctor to return could now be set directly by the client without need to
bootstrap the server with a specific property. This allowed for much easier
configuration than was previously had.
InitializationOptions
Once it was clear that configuring Metals via the client was desirable, a closer
look was taken at InitializationOptions that can be passed in during the
initialize
request. Since any value is able to be passed in this way, a decision was made
to fully migrate all the possible settings that were previously set as server
properties (except a select few that we'll touch on later), and also move all
the of settings that could be set under experimental to
InitializationOptions as well. This ultimately allows for clients to fully
configured Metals via InitializationOptions without the need to set any server
properties. In theory this also meant that you could not use the same Metals
executable for VS Code, Vim, or Emacs since the server is fully being configured
by the client itself. The current settings that can be passed in and their
defaults are explained in detail here on the
website,
but the interface is as follows:
You'll notice that this allows for a much finer grained configuration if the
client chooses to set certain values. Everything from whether or not the Scala
Presentation Compiler should populate the SignatureHelp.documentation to
whether or not the editor supports opening a new window after using the
metals.new-scala-project command can now be easily configured. Fully
configuring Metals through InitializationOptions is now the recommended way to
configure Metals.
Are there still server properties?
While all of the old server properties still exist for Metals, it's no longer
recommended to use them to configure Metals. However, there are still a few
server properties that remain only server properties since they are not meant to
be widely used, and aren't exactly recommended to use for the average user. You
can see an up to date list of these here on the
website
and what functionality they provide.
Conclusion
As of Metals 0.9.2 it's fully possibly for all clients to use a default
bootstrapped Metals that can fully be configured via InitializationOptions.
There is a freshly updated Integrating a new
editor section on
the website to help explain how to exactly configure a client for usage with
Metals. As always, don't hesitate to reach out on any of the various channels
located in the footer or submit an issue to either improve documentation or to
log a bug. Also as a reminder, there is a separate repo for
metals-feature-requests.
Metals is a language server for Scala that works with VS Code, Vim, Emacs,
Sublime Text, Atom and Eclipse. Metals is developed at the
Scala Center and VirtusLab
with the help from Lunatech along with contributors from
the community.
Previously, when either a build tool was chosen for a workspace or the build
import notification was dismissed the only way to revert that choice was to
delete the .metals directory. In this release we added two different ways to
reset it:
via a new button available in the doctor (Visual Studio Code):
using a new command metals.reset-choice (other editors):
Miscellaneous improvements
Named parameters completions fixed to work in cases where the method was
defined later in the class.
Add option to not add the Bloop plugin in Gradle builds. This might be useful
if you already define Bloop plugin in your workspace, otherwise it's not
recommended.
Find all templates from the giter8 wiki page for the New Project Provider
Contributors
Big thanks to everybody who contributed to this release or reported an issue!
We're happy to announce the release of Metals v0.9.1, which focused on fixing
issues with the recently released Scala 3 support, Ammonite support and a couple
of new features.
Metals is a language server for Scala that works with VS Code, Vim, Emacs,
Sublime Text, Atom and Eclipse. Metals is developed at the
Scala Center and VirtusLab
with the help from Lunatech along with contributors from
the community.
Dropped support for Scala 0.23.0 and deprecated the 0.24.0-RC1 version.
Multiple build tool selection within a workspace
Ammonite support
Thanks to great work by alexarchambault we
now support Ammonite script files. Ammonite enables you
to create scripts that can easily be ran from the command line, without the
overhead of setting up a build tool while still allowing you to download and use
dependencies.
The support includes most of the LSP features such as diagnostics, completions,
references, go to definition, but does not include running or debugging the
scripts. This new feature works by starting an additional Ammonite BSP server
that compiles the scripts and provides additional information about them such as
Scala version or information about the added dependencies. You can change the
default JVM parameters for the server such as -Xmx, which will limit the used
memory in Metals settings. These can be added via your metals editor extension
using the newly created metals.ammoniteJvmProperties setting. The Ammonite
server can also be started and stopped manually using the new commands
ammonite-start and ammonite-stop.
Each of the scripts first need to be imported into the Ammonite BSP server,
which can be done manually by clicking on the pop up whenever a new script is
opened or selecting automatic import at the start, which will import any open
scripts automatically.
It's important to note that this is an early approach to Ammonite support, which
might still require some improvements both on the Metals and Ammonite side. You
can learn more about the new feature or join the discussion in the
blogpost
on the Scala contributors forum.
Some of the notable features of Ammonite scripts are:
Import other scripts: Metals provides completions to select existing files
based on the filesystem information
The Scala version is independent from any build tool used in the workspace and
without specifying the exact version it will use the default Ammonite Scala
version.
To learn more about Ammonite please visit the documentation website at
https://ammonite.io.
Worksheet dependency support
In addition to Ammonite support, which will be useful to anyone interested in
Scala scripting, we've also improved the support for Metals Scala worksheets.
Thanks to the efforts of olafurpg in
mdoc, which powers worksheets, users are now able
to import dependencies directly inside of their Scala worksheet with completions
and diagnostics working right from the start.
You can add them using the following syntax:
$ivy.`organisation::artifact:version`
For example:
$ivy.`com.lihaoyi::scalatags:0.9.0`
:: is the same as %% in sbt, which will append the current Scala binary
version to the artifact name.
New project provider
Creating new Scala projects is usually a bit of work to get started, which is a
problem for both beginners and experts alike. Normally you don't want to spend a
lot of time figuring out the best setup for starting with a new technology or
the language itself.
There are great tools like giter8, which
is used in the sbt new command, that enables people to use already existing
Scala templates found on Github such as
https://github.com/scala/scala-seed.g8.
The problem is when you don't use sbt or you don't know the exact template you
want to use.
To address this, we've added an additional command called New Scala Project
that enables users to reuse the same mechanism from the comfort of your editor.
Firstly, you can choose from existing templates, either curated by the Metals
team, ones existing on the giter8
wiki page or
alternatively an entirely custom template. Then you can choose the exact
location for the new project and the name. Afterwards, Metals will run giter8 to
create the project and offer to open that new project.
The command is also available as a button in the welcome view of the Visual
Studio Code Metals extension, which means it will be visible in case there are
no imported projects in the current workspace.
The first curated templates were chosen by the team, however we are happy to
include more so that it's easier for people to discover new amazing libraries or
frameworks.
Multiline string improvements
There are two new quality of life improvements when it comes to multiline
strings. Firstly, thanks to mlachkar we now
automatically add stripMargin method invocation when using newline in a
multiline string if that string uses | and has no existing stripMargin:
This behaviour can be disabled in Metals settings using
metals.enableStripMarginOnTypeFormatting.
Another useful improvement coming from colineto
is a new code action that can easily convert single string into the traditional
multiline string with | and stripMargin at the end:
Multiple workspace build tools selection
Previously, Metals would only pick up a single build tool in a workspace even if
in reality there were multiple available ones. To help with that we added a
prompt to choose the desired build tool in workspaces with multiple build files.
An example situation where this is needed is when you have a project with both a
build.sbt and build.sc, but the build.sc is what you use for your build
definition. Previously if both were detected, it was automatically considered an
Sbt workspace, however now it's possible to choose.
In case of multiple build tools in single workspace you can see which one was
used to import project in 'Metals Doctor' view. If you choose the wrong one, or
change the main build tool later on, you'll need to remove the .metals/
directory to reset the decisions.
This great new feature was contributed by ckipp01!
Miscellaneous improvements
Fix run/debug in Maven workspaces.
Always run newest sbt version if none is specified.
Fix find references for Scala 3 on Windows.
Pick jvm targets with higher priority when using run/debug without specifying
the exact build target.
Make breakpoints work properly in Scala 3 and in case of nested classes.
Exhaustive pattern matching in the case of sealed upper bound types.
Compile before renaming instead of showing an error.
Fix issue with symlinked source directories.
Fix missing references for synthetic companion objects.
Automatically add -J if it doesn't already exist to java properties when
running or debugging.
Fix go to definition for JDK 11 library sources.
Keep modifiers when implementing abstract members.
Fix auto imports position when using package objects and multiple package
definitions.
Fix issues in files with Scala 2.13 specific syntax like for example
underscore numeric literals (val num = 100_000).
Always run Mill in interactive mode.
Improvements to hover in Scala 3 files.
Make sure auto imports are correct for Ammonite scripts
Contributors
Big thanks to everybody who contributed to this release or reported an issue!
We are happy to announce the release of Metals v0.9.0, codename "Lithium", which
main focus is introducing support for Scala 3 starting with versions 0.23.0 and
0.24.0-RC1. We also added support for Scala 2.13.2 and a number of other useful
improvements.
Metals is a language server for Scala that works with VS Code, Vim, Emacs,
Sublime Text, Atom and Eclipse. Metals is developed at the
Scala Center and VirtusLab
with the help from Lunatech along with contributors from
the community.
Automatically add '+' on newline when inside a string
New Code action: "Import all missing symbols"
Basic Scala 3 support
For a couple of the last months we have been working on making Metals work with
the Dotty compiler, which will become the new Scala 3. This effort included
contributions to Metals, Bloop as well as to Dotty. Thanks to the great help
from the Dotty compiler team, we now have an option to generate semanticDB files
used for our internal indexes, which allowed some features to work without any
changes to the core code. It is also important to mention that without
jvican and his Bloop project, which already
supports Scala 3, all this would have taken a much longer time.
That said, there are some issues that are lacking in the Scala 3 support that
are available for 2.x versions. Most notably, we are still missing all of the
more advanced completions, filtering and sorting of completion items or auto
imports. There are also some possible issues connected to optional braces and
top level methods features. In the upcoming months we are planning to address
most of these issues and implement the lacking features.
The first supported versions will be 0.23.0 and 0.24.0-RC1, which are the
latest stable and the latest release candidate respectably. We plan to always
support the latest stable and release candidate until there is a more stable
release cycle for Scala 3.
Please do report any issues you encounter, especially connected to some new
Scala 3 features, which will be an immense help to the team.
Improvements related to Bloop/Metals integration
There have been multiple reported issues in the last weeks about hanging
compilation, which can make the Metals workspace hard to use. Our top priority
has been figuring out all the possible issues both in Metals as well as in
Bloop. Thanks to some fixes done by jvican, and
some work on the Metals side on the Bloop integration we're hopeful that some of
the issues are becoming less frequent. These fixes are included in this release.
We also reworked the Metals tree view to highlight some commands that a user can
use to fix their workspace as well as added two new commands:
Clean compile workspace - clean compile the whole workspace - might be
needed in case of broken compiler caches.
Restart Bloop server - restart the Bloop build server, which should help
with the cases where compilation would hang.
Even if those commands help, do not hesitate to report any issues. We are also
monitoring the situation ourselves and investigating all problems encountered.
Automatically add '+' on newline inside a string
The Metals team was recently joined by mlachkar,
an engineer from the Scala Center, who already contributed a number of features
and bug fixes to the project. Thanks to her, we can now easily enter a newline
inside a single line string and that string will be correctly split with an
additional +.
Code action to import all missing symbols
Previously, it was only available to import one symbol at a time in case of
missing imports. Thanks to colineto we now have
the ability to import everything in bulk for every unambiguous import available.
Unambiguous in this case meaning that there is only one possible import to
choose from.
Miscellaneous improvements
Added an option to ignore .scalafmt.conf creation message.
Fixed hanging while debugging if workspace had errors.
Fixed issue with folding in non 2.12.11 workspaces.
Turn off "Go to parent" code lenses by default due to performance problems in
large workspaces.
Fixed false parsing errors in 2.13.x workspaces.
Added date string to metals logs.
Fixed issue with additional src directories being created automatically.
Fixed "Go to implementation" to work with local aliases.
Fixed auto-import issue in package objects.
Contributors
Big thanks to everybody who contributed to this release! We had a lot of new
contributors doing some really exemplary work.
Metals is a language server for Scala that works with VS Code, Vim, Emacs,
Sublime Text, Atom and Eclipse. Metals is developed at the
Scala Center and VirtusLab
with the help from Lunatech along with contributors from
the community.
Metals will now calculate if any definition of a method in the current file
overrides another method, in which case it will show a new lens next to the
method's position. Once clicked, the user will be able to go to the super
method. Lenses also link to methods in external dependencies and are displayed
in files from libraries. For this new feature to work make sure that you enable
code lenses in your client.
If they are found to be disturbing your workflow they can be easily disabled via
the metals.superMethodLensesEnabled configuration option - they are enabled by
default. For example in Visual Studio Code:
These new lenses should be quick to calculate but if you notice significant
slowdown you can also disable them, since when disabled they are not only not
displayed but also not calculated at all.
There is also an exposed server command goto-super-method that can be mapped
and used through shortcut in Visual Studio Code.
It is possible to also navigate the whole inheritance hierachy at once using the
new super-method-hierarchy command.
This new command can be invoked on a method definition. It calculates super
method hierarchy and if more than one position is found it displays a quickPick
window (same as the new scala file feature) which displays all super methods and
allows a user to select one and jump to its definition.
As an example in Visual Studio Code it can be bound to a shortcut this way:
Thanks to kpbochenek from VirtusLab for this
new feature!
Support for 'launch.json'
Previously, it was only possible to launch main classes or tests via code lenses
that would appear above a particular class. Now, we add a way for a user to be
able specify the name of the the class or test to run. We will then
automatically try to detect the build target, which that class/test belongs to
and run it. In this release, we also add a way to specify the main class
arguments.
While this will be primarily useful for the Visual Studio Code Metals extension,
it will also make it easier for other editors that support the Debug Adapter
Protocol. To obtain the uri needed for starting a debug session users can now
execute the debug-adapter-start command with params:
buildTarget is an optional parameter, which might be useful if there are
identically named classes in different modules. A uri will be returned that can
be used by the DAP client.
More information about adding support for debugging is available
here.
This awesome new feature was contributed by
alekseiAlefirov from VirtusLab.
New 'Create new symbol...' code action
Previously we would propose to import a symbol (if available) in response to
"missing symbol" errors. Now, thanks to gabro, we
also propose to create a new class, case class, trait or object.
This might be useful when sketching out a domain model and should improve user
experience for fast prototyping.
Miscellaneous improvements
package is no longer added on imports from package objects
if user right clicks on a file in Visual Studio Code the option for
New Scala file also shows now the same as for directories
a multiline string can now be formatted exclusively when using
format selection on that string
added in ... to signify truncation in worksheets
fixed hover on Scala App trait and several other cases that showed up on Scala
Play projects
messages about upgrading Scala versions are now more valid to the user
references in a file are sorted before showing them
better cursor position when creating new files using the New Scala file
command
added "case class" option in NewFilesProvider
Contributors
Big thanks to everybody who contributed to this release!
We are happy to announce the release of Metals v0.8.3, which main purpose is
adding support for the new Scala version, 2.12.11. Additionally, we included a
couple of recent fixes.
Metals is a language server for Scala that works with VS Code, Vim, Emacs,
Sublime Text, Atom and Eclipse. Metals is developed at the
Scala Center and VirtusLab
with the help from Lunatech along with contributors from
the community.
Metals is a language server for Scala that works with VS Code, Vim, Emacs,
Sublime Text, Atom and Eclipse. Metals is developed at the
Scala Center and VirtusLab
with the help from Lunatech along with contributors from
the community.
Thanks to yet again amazing work by
tanishiking, we now support the quick fix code
action for implementing abstract class members. This code action is available in
case of errors and works in the same way as the recent
"Implement all members"
completion. It will add any missing abstract members at the top of the class
with the default implementation of ???.
New file provider
In the last release we added support for worksheets, which are an easy way to
quickly evaluate some code. To create a new worksheet you need to create a file
with the extension .worksheet.sc, which was not that easy to figure out. To
fix that situation, thanks to
alekseiAlefirov, we now have a menu to
create different types of new files including classes, traits, object, package
objects and of course worksheets. At this time it's only available in the Visual
Studio Code and coc-metals extensions.
You can also just use the command Metals: New Scala File, which will use the
current file's directory and create the new file there. And additionally, when
using a relative path like a/b/C Metals will create all needed directories and
add a proper package declaration to the new file.
Enable rename preview for Visual Studio Code
Rename previews were added in the last Visual Studio Code
release, which
enable users to see what will be changed when a rename is executed. Due to
optimization and UX reasons Metals renamed symbols in closed files in the
background without informing the editor. However, this also causes the previews
to be misleading, since they might not be complete.
To fix that situation we now send all the files to VS Code, which then is able
to display the preview. We do it, however, for up to 300 files, which threshold
was experimentally estimated. When the number of files reaches over that number,
we revert to the old behavior of not opening closed files. The reason for this
is that in some cases for larger numbers of files the editor could hang and
become unresponsive.
Debug in Emacs
In the last release run and debug support was only available for Visual Studio
Code, but thanks to amazing work by the contributors it is now possible to use
it in Emacs via lsp-mode's metals
settings and dap-mode.
Other changes
This release includes mostly fixes and minor features, which is due to the large
scope of the last one. We concentrated this last month on stability and making
sure everything is up to scratch. Those minor changes included:
use bloop.export-jar-classifiers property when importing the build from sbt
ignore bad compiler options passed by users in order not to break completions
add an override for the Bloop plugin version and promote it to LSP settings
fix onTypeFormatting when used in top level multi-line strings
fix issues when go to implementation resolves local symbols
change the non-fatal jar error to debug rather than log warning
add support for worksheets without a build target by defaulting to Metals
Scala version
rename file only if the renamed symbol is directly enclosed by a package
fix exhaustive match completion on Java enums
use workspace level Gradle wrapper if present for bloopInstall
fix onTypeFormatting issue with multiple pipes on a line
fix rename issues with backticks
add documentation on how to use proxies and mirrors
Contributors
Big thanks to everybody who contributed to this release!
Again, we have some new contributors and a lot of returning ones!
We are excited to announce the release of Metals v0.8.0, codename Cobalt. This
release includes a large number of new features and improvements, which have
been under development since September 2019.
Metals is a language server for Scala that works with VS Code, Vim, Emacs,
Sublime Text, Atom and Eclipse. Metals is developed at the
Scala Center and VirtusLab
along with contributors from the community. Recently, Metals has also gained
support from Lunatech with the contributions from
@ckipp01. We are extremely grateful for the
growing support from the community and businesses alike, which shows in the
number of new contributions and their quality.
It is now possible to run and test directly from VS Code using the new "Run",
"Test", "Debug" and "Debug test" buttons. The debug buttons support debugging
with breakpoints. It's possible to insert breakpoints in Java and Scala sources
for both workspace sources as well as library dependency sources.
To support other editors please take a look into the documentation on the Metals
website.
Known breakpoints limitations we are working on:
debugging is only supported in VS Code at this moment, we hope to increase the
editor support in the future. To support debugging, editors need to implement
the
Debug Adapter Protocol
breakpoints may not work as expected in all source locations (example: inner
classes, ambiguous names, lambdas). Please share your feedback by reporting
issues!
Navigation
Go to implementations
Metals now implements the textDocument/implementations LSP endpoint, which
enables all supported editors to display a list of all implementations of
abstract classes or members.
Finding implementations also works for symbols outside of the workspace, at the
price of a small performance penalty for the first invocation.
The work done for this feature was also instrumental for implementing the Rename
refactor (see below).
Refactor
Refactoring support is one of the most requested features in Metals. In this
release, we started by implementing the most commonly used refactors: rename and
import missing symbol.
We plan to add more common refactors along the way. Make sure to check out the
ones that have already been proposed
and consider suggesting other refactors that are essential in your development
workflow.
Rename symbol
Thanks to the implementation of the Go to implementations feature, we were
able to work on a proper rename for any workspace symbol that will rename all
occurrences of a symbol even if that symbol is a part of a class hierarchy.
There are a couple of cases in which rename might behave differently based on
the particular symbol being renamed:
renaming an overriden symbol will rename all occurrences for both parent and
all children overriding that symbol
java symbols are not renamed
renaming "hashCode", "unapply", "unary_!", "!" is not supported, since they
change the semantics
methods starting with : can only be renamed to ones with the same first
character to make sure code compiles afterwards
renaming apply will change all occurrences with just () to a full name
.newname()
if renaming a class with the same name as the file, the file's name will also
be renamed
companion objects will also be renamed along with their companion classes
Import missing symbol
Another refactor that is commonly requested is the ability to fix a compilation
error by auto-importing a symbol present on the classpath.
This was previously possible in Metals only during completions, but we were
lacking what LSP calls a code action.
Code actions are context-sensitive actions that are proposed to the user in
order to fix an error or to perform a relevant refactor.
Thanks to the work of @gabro we now have a basic
architecture in place for supporting code actions and we were able to implement
this feature.
Worksheet support
Thanks to great work by @olafurpg and some
additional refinements by
@alekseiAlefirov, worksheets are now
available in all supported editors.
Worksheets are a way to evaluate code in real time to test and prototype any new
features in a simple way. To create a worksheet all that is needed is to create
a file with the extension .worksheet.sc within the source directory of your
workspace (like /src/main/scala) and Metals will take care of the rest.
There are two ways worksheets are implemented for different editors. One is with
an additional extension to LSP called Decoration extension and it's used by
Visual Studio Code and coc-metals.
Visual Studio Code:
The other way worksheets are implemented for all other editors that don't
support the Decoration extension is using workspace/applyEdits and comments
with hover for larger results.
Sublime:
Build tools
In order to make the integration between Bloop and Metals a smoother experience,
several new improvements are included in this release. There're based on
feedback from users as well us our own experiences while working with Metals and
should make the overall experience of importing the build and compiling much
better.
SemanticDB is resolved inside Bloop
Metals requires the SemanticDB compiler plugin for a number of features to
function properly. Because of that it was quite difficult to add it
automatically in all supported build tools even if those supported Bloop itself.
Perfect examples are Seed and Fury, which use Bloop to compile code, however
adding a plugin automatically would require changes to their core code.
Currently, thanks to
recent changes, Metals can send
information about the SemanticDB version, which Bloop uses to automatically
download and configure the SemanticDB scalac plugin. Thanks to that no changes
in the build tool itself are needed. Particular changes in regards to build
tools are:
Gradle - predef script code used in automatic import is now simplified a lot
and works with even more customized workspaces. The only thing it needs to do
is add the Bloop plugin and run bloopInstall, which can easily also be done
manually by the user.
Maven - no manual configuration is now needed. To import automatically just
the plugin is needed to be invoked with a setting for downloading sources.
Sbt - the metals-sbt plugin is now removed and the Bloop plugin is now added
via automatically generated ./project/metals.sbt file and ran when imported
automatically. Thanks to this solution it should be possible to reuse Metals
compilation in the upcoming feature for offloading compilation in Sbt.
Mill - logic for adding semanticDB plugin is removed from Mill.
Fury, Seed - no changes were needed for the semanticDB integration and should
work out of the box.
Switch to to using Bloop Launcher
Instead of using internal Metals logic, we now use the Bloop Launcher, which
enables us to either connect to an existing Bsp server or start a new Bloop
instance with the specified version if none is running. This greatly simplified
the connection to Bloop and enabled us to work on further improvements.
Restart Bloop automatically if newer version is needed
Whenever Metals is started and connects to the Bloop build server it receives
information about the version it is running. We compare that version to the one
needed by Metals to make sure everything is properly working. If the current
running version is older we offer to automatically restart it with the newer
version. However, this may not work if Bloop was installed manually.
Automatically reconnect to Bsp/Bloop if connection is broken
There were numerous issues reported that the connection to Bps or Bloop was
being lost, which causes Metals to behave erratically due to no compilation
being run. To solve this, we now detect if the connection is closed and offer
the user the option of automatic reconnection. This works both when the build
server was down and when the connection was just interrupted. It should also
solve the issues on MacOs with dropped connection.
Completions
Completion to add all abstract members
In the past when you were implementing an abstract member in a concrete class,
you'd see the completion option to override the member. However, if you wanted
to implement all of the abstract members, you'd need to do each one
individually. Now you'll see a new completion option in the scenario to
Implement all members which will implement all the members at once.
Support scaladoc auto completion on type /**
Thanks to recent work by tanishiking Metals
now supports auto completing scaladoc for method definition and class definition
on typing /**. More details about it can be found in
the pull request.
Better support for Vim via coc-metals
In order to better support the Vim experience with Metals, coc-metals extension
was created which is an extension for coc.nvim, the most popular LSP client for
Vim and Neovim. With this new extension comes a whole bunch of new features for
Metals + Vim users.
automated installation
easier configuration options
easier workspace commands
embedded doctor
input box support
implementation of the decoration protocol (Neovim only)
Support for java 11
Thanks to @isomarcte we now also run all tests
on JDK 11, which enables us to be more confident about the support for it. With
some additional changes to the documentation we now can fully claim that support
for JDK 11 is available.
Other changes
This version includes approximately 25% of the Metals git commit log, which
makes it impossible to explain every possible improvement in these release
notes. Some other features and fixes that we should mention are:
fix for handling abstract var overrides
add an empty line after the package declaration before import
sort auto-completed exhaustive matches by declaration order
encode the workspace path directory in build digests
tone down "No SemanticDB" warning
send Tree View update notification on first no-op compilation.
enable goToDefinition when cursor is at end of symbol
prioritize build targets with supported Scala versions.
add automatic formatting of multi-line stripMargin strings on paste
remove support for 2.12.7
Contributors
Big thanks to everybody who contributed to this release!
We had a lot of new contributors that provided us with some amazing new features
and with some amazing quality.
