rossabaker/lsp-scala

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

tmciver opened this issue · 15 comments

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..

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.

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.

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 🤞

@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.

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

@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.

@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.

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.

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.

@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.

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!

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.

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.

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.

@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.