Closed binary132 closed 5 years ago
You mean both MELPA stable and MELPA unstable of lsp-mode?
Having the same issue here.
Using the latest versions from melpa
seems to not be working.
Using stable versions from melpa-stable
seems to work well.
Any idea why? Maybe I could dig into it later
@rossabaker -- both lsp-mode and lsp-scala, in all 4 combinations, iirc @JesusMtnez -- what versions of the Emacs lsp package, lsp-scala, and metaLS are you using?
I've been working around it by commenting out these lines in lsp-scala.el:
; Legacy support for lsp-mode <= 5
(lsp-define-stdio-client lsp-scala "scala"
(lambda () (sbt:find-root))
(lsp-scala--server-command))
I'm using metals
0.3.3
I got it working the old way, using lsp-mode
and lsp-ui
pin to melpa-stable
versions. But doing so, you need to configure it like this:
(use-package lsp-mode
:pin melpa-stable)
(use-package lsp-ui
:pin melpa-stable
:hook (lsp-mode . lsp-ui-mode))
(use-package lsp-scala
:after scala-mode
:demand t
:load-path "local/lsp-scala/"
:hook (scala-mode . lsp-scala-enable))
The addition of this package to MELPA is hung up on concerns about the with-eval-after-load
call, which could go away. Maybe it's time to decide that we support either stable or unstable and stop trying to do both.
Does anyone have a strong preference for one over the other? Since metals itself is a bit bleeding edge, and pinning seems to be a non-default, I'm leaning toward dropping support for stable, which would look like @SethTisue's solution.
@rossabaker I agree. I think trying to maintain support for both right now does not seem to be a priority right now, since metals
in a high WIP right now.
This should be fixed by #18. I'm going to look to follow up with removing the legacy support altogether to get rid of that with-eval-after-load
call and hopefully get past the objection to getting this into MELPA.
I get the following error upon entering scala-mode, both using MELPA stable and MELPA:
File mode specification error: (void-function lsp-define-stdio-client)