See error "LSP :: No LSP server for scala-mode." when opening Scala file

[tmciver]

Emacs version: 25.2.2
lsp-scala version: commit b68820c
lsp-mode version: 20190123.1915 (from MELPA, non-stable)

Here's my LSP-related configuration (from here)

;; Enable scala-mode and sbt-mode
(use-package scala-mode
  :mode "\\.s\\(cala\\|bt\\)$")

(use-package sbt-mode
  :commands sbt-start sbt-command
  :config
  ;; WORKAROUND: https://github.com/ensime/emacs-sbt-mode/issues/31
  ;; allows using SPACE when in the minibuffer
  (substitute-key-definition
   'minibuffer-complete-word
   'self-insert-command
   minibuffer-local-completion-map))

;; Enable nice rendering of diagnostics like compile errors.
(use-package flycheck
  :init (global-flycheck-mode))

(use-package lsp-mode)

(use-package lsp-ui
  :hook (lsp-mode . lsp-ui-mode))

(use-package lsp-scala
  :load-path "/home/tim/workspace/scala/lsp-scala/lsp-scala"
  :after scala-mode
  :demand t
  ;; Optional - enable lsp-scala automatically in scala files
  :hook (scala-mode . lsp))

When visiting a Scala file, the mode line shows LSP :: No LSP server for scala-mode..

[rossabaker]

I can confirm the same problem.

The readme for lsp-scala now mentions needing to set lsp-language-id-configuration. I tried adding the following to lsp-scala.el, and see it in the list:

(add-to-list 'lsp-language-id-configuration '(scala-mode . "scala"))

But I still get the same error. I searched GitHub to see how other packages do it, and all I could find was an init.el for a different language. I'm puzzled. Question pending to Gitter, which I'll check on in the morning.

[JesusMtnez]

Trying to reproduce this error, with no luck. The exact same configuration is working for me...

I've check lsp-language-id-configuration and there is no item for scala-mode, but it's working.

I'll keep looking.

[JesusMtnez]

Now I reproduced the error.

@tmciver Could you please check the generated metals-emacs binary is available on your $PATH? I got that error because I removed the logic I had to import my PATH variable from zsh in Emacs. Try:

M-x shell-command RET metals-emacs

If it worked, then metals-emacs is accesible for Emacs. If not, it means you need to tell lsp-scala where it is, setting lsp-scala-server-command, like in README.md configuration in this repository:

(use-package lsp-scala
  :load-path "~/path/to/lsp-scala"
  :after scala-mode
  :demand t
  :hook (scala-mode . lsp)
  :init (setq lsp-scala-server-command "~/bin/metals-emacs"))

Let us know if this was the problem 🤞

[tmciver]

@JesusMtnez @rossabaker Thanks for looking into this. I ran M-x shell-command RET metals-emacs and it successfully started metals-emacs, so it looks like the problem lies elsewhere.

[JesusMtnez]

🤔 So weird... No clue why I can not reproduced it 🤔

[rossabaker]

@JesusMtnez Did you have to add to lsp-language-id-configuration

I set lsp-scala-server-command to an absolute path, instead of the default "metals-emacs", and it worked. My metals-emacs is in my $PATH, so I don't understand why the absolute path was necessary. I'll try again this weekend, but maybe that gets @tmciver back in business.

[JesusMtnez]

@rossabaker I didn't need to set lsp-language-id-configuration.

https://github.com/JesusMtnez/emacs.d/blob/master/modules/module-scala.el#L41-L48 that is my current configuration, working right now.

About $PATH, I also have metals-emacs in my $PATH, but when I open Emacs in a GUI (not in a terminal), it does not inherit it properly since most of my setup for $PATH is in my .zshrc. That's why I know I need to include the full path in lsp-scala-server-command.

Another possible solution could be using purcell/exec-path-from-shell package. Something like:

(use-package exec-path-from-shell
  :ensure t
  :demant t
  :config 
  (progn
    (setq exec-path-from-shell-check-startup-files nil)
    (exec-path-from-shell-copy-env "PATH")))

That would make sure the same setup is made in your terminal for $PATH is copied to exec-path in your Emacs.

[tmciver]

I was forced to duplicate my emacs setup on an older machine due to a hard drive failure in my main computer. Having done that I no longer have this problem; the LSP server is starting up fine. I think it may have been because I had the path to lsp-scala wrong (note the extra lsp-scala in the path). So I would say this bug is resolved if it weren't for @rossabaker experiencing it.

On an unrelated issue, now that the LSP server starts I see the following messages printed:

LSP :: Connected to [scala:15890 status:starting].
error in process filter: or: Symbol’s value as variable is void: method
error in process filter: Symbol’s value as variable is void: method
error in process filter: or: Symbol’s value as variable is void: method
error in process filter: Symbol’s value as variable is void: method

I have no idea where this is coming from; it may having nothing to do with lsp-scala/lsp-mode.

[gigawhitlocks]

Hi everyone, I encountered this error and have found the appropriate fix. @JesusMtnez's solution is the most complete. The simplest version is just to add this to your init.el or .emacs:

(add-to-list 'exec-path "/usr/local/bin" t)

where "/usr/local/bin" is the location where you have installed metals-emacs.

And that's it. Restart Emacs and you should be able to connect/reconnect to the LSP server without issue.

[stewSquared]

@gigawhitlocks I don't believe this would solve the particular problem @tmciver had. From his earlier post:

I ran M-x shell-command RET metals-emacs and it successfully started metals-emacs, so it looks like the problem lies elsewhere.

This implies metals-emacs is already in 'exec-path.

I'm also seeing the same symptoms as the OP. metals-emacs is in my path. I'm debugging right now, but I definitely wouldn't call the issue closed.

[gigawhitlocks]

Confusingly, emacs has a PATH variable and an exec-path variable, and I am not sure but I suspect M-x shell-command references the latter and lsp the former. I hope that helps with your debugging @stewSquared and good luck!

[stewSquared]

Thanks @gigawhitlocks I did double-check that I could both use shell-command and see the proper path in 'exec-path, so it doesn't seem to be a path problem of any sort.

I did also attempt @rossabaker's fix of setting 'lsp-scala-server-command, since it's undefined for me (and 'scala-mode is non-existent in 'lsp-language-id-configuration). The fix worked for Ross, but has no effect for me. I tried setting it both to "metals-emacs" and the absolute path. As in Ross's case, adding the scala-mode pair to 'lsp-language-id-configuration has no effect for me.

[stewSquared]

So! I decided to check package versions and realized that I'm seeing this is because I'm using lsp-scala from version 0.6.0 of lsp-mode . According to #28, this package is now part of lsp-mode, but it's important to note that it's not yet in melpa stable (0.6.0).

For anyone following along from the metals documentation, you might find that installing lsp-mode fails because of a missing dependency on spinner.el. Installing it explicitly fails when connecting to elpa with a 400. I don't know why, so I ended up downloading the source manually to make lsp-mode happy.

I'm not sure this is the right place to post about this (post in metals? lsp-mode?), since this project is deprecated, but hopefully someone else will find this info useful when they search for this error.

[rossabaker]

Are you running into Malabarba/spinner.el#14, maybe? I'm curious why I didn't see that. I'm now managing my config through nix, so that may have worked some magic.

I would check with the lsp-mode folks, who have been quite helpful.

[stewSquared]

@rossabaker I'm actually seeing the "Bad Request" when attempting to install any elpa gnu package. I get these issues with clean cache and minimal config, so I suspect what I'm seeing might be resolved in one of these two recent threads:

https://www.reddit.com/r/emacs/comments/cdei4p/failed_to_download_gnu_archive_bad_request/
https://www.reddit.com/r/emacs/comments/cdf48c/failed_to_download_gnu_archive/

edit: Yup! It's some GNU TLS bug. Work around from this comment:

(setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")

Apparently, this has only shon recently. More and more emacs users are reposting the same issue in different manifestations. So, PSA.