rossabaker
Move to MELPA or fold into lsp-clients
It's silly that we have to clone this instead of installing from a package manager. We should either:
- Justify our existence as a standalone project and submit to MELPA.
- PR ourselves to lsp-clients.el and dissolve this project.
The metals-specific functionality in this library are:
- The four commands built on
lsp-send-execute-command - Sending
lsp-scala--config-options, which was useful in 0.2 but is empty now.
By staying standalone, we have Scala people doing the releases. We could add more metals specific commands without wondering whether we are still a "simple" client.
By merging into lsp-clients.el, we would have Elisp people doing the releases (i.e., we'd be free of fools like me.) Users would have one less package to configure. I'm leaning toward this being the better option.
Discuss.
Justify our existence as a standalone project and submit to MELPA.
A bad thing about merging it to lsp-clients.el is that we will lose eglot compatibility.
Seems like for few peoples like me lsp-mode doesn't work for some reason but eglot going well (maybe it's doesn't work because of 'rootUri' detection bug or another build import issue).
For what it's worth, the vim installation instructions use vim-lsc directly without a custom Metals package https://scalameta.org/metals/docs/editors/vim.html. My impression is that this is working OK for people, at least no one has requested a vim-metals package. For commands, people write the raw JSON-RPC commands directly
:call lsc#server#call(&filetype, 'workspace/executeCommand', { 'command': 'build-import' }, function('abs'))
@strobe Does this package help with eglot at all? Trying eglot is also on my todo list, but I assumed that this package would be of no use in that world.
I've engaged the lsp-mode Gitter to get more opinions on the right place for this. Will report back.
The lsp-mode folks say they'd accept a PR, but that they lack expertise in the individual languages. They also mentioned that it's hard for people to install separate packages, but Metals has a really good docs story thus far. Finally, we'd be the first client there with extension methods. I think maybe a separate package in MELPA is the right place for this after all.
@strobe Does this package help with eglot at all? Trying eglot is also on my todo list, but I assumed that this package would be of no use in that world.
Yeah, my current setup which works looks like this https://gist.github.com/strobe/36f42d7867b0fb647f39d43aa2a9a4b4
and for some reason, if I try to change eglot to lsp-mode in that config then metals produce 'Skipping build import' messages and unable work properly.
But this solution with eglot is not clear because lsp-ui required files from lsp-mode therefore it should be installed anyway.
I tried eglot last week. You don't need lsp-scala at all to use eglot. The idea of eglot is to offer a common way to use lsp for all languagues, instead of having one definition per language as lsp-mode does. So you just need to install eglot and run M-x eglot in when you open a *.scala file
omg, you are right - I was completely wrong how that works together.
I was thought that lsp-ui required for navigation functions like lsp-ui-peek-find-definitions
and lsp-scala needs to start metals via lsp-* package but seems like 'eglot' just works without anything else and has eglot--xref-reset-known-symbols with defaults keybindings.
sorry, for that
@rossabaker Time has passed and this package has become slightly outdated. Now all clients have list of defvars for custom settings. Also I think they don't mind of custom commands that use lsp-send-execute-command? So can this be reconsidered? Having this package as part of lsp-mode can help to keep it up-to-date. I can make a PR to lsp-mode myself if you don't have time for this.
@kurnevsky I think this is a good idea. It seems like more changes are being driven by lsp-mode than metals at this point, and it now makes a lot of sense to get into the mainline. I'd be in favor of sending a PR.