Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect if LSP_USE_PLIST is not set before loading lsp-mode (server starting...) #4455

Open
alanpearce opened this issue May 21, 2024 · 0 comments

Comments

@alanpearce
Copy link

I appeared to have LSP_USE_PLISTS correctly set both for the installation and initialisation of lsp-mode, but it stopped working when I switched to running Emacs as a daemon and was harder to track down than it needed to be.

When opening a buffer that would call lsp, the server(s) would be stuck starting indefinitely. I couldn't work out what the issue was easily; *lsp-log* showed that the path was correct but none of the other buffers showed anything that would hint to problems with LSP_USE_PLISTS. Fortunately I decided to run lsp-doctor and saw that the plist feature was marked as optional and not OK as I expected.

It would be nice if lsp-mode would detect being run without plists when installed as such and perhaps show an error in the echo area and perhaps highlight the issue when lsp-doctor is called by making the plists item red instead of orange (after a longer time, I could easily have forgotten that I had set this up). An FAQ item could also be reasonable: "server stuck starting with plists enabled?...". If you don't agree with any this, feel free to close the issue; if someone searches for it in the future, hopefully they'll find it anyway.

The cause of the issue was in my own config, namely that I defer loading lsp-mode in a standalone Emacs session, but not when run as a daemon, roughly as below:

(setq use-package-always-demand (daemonp))
(use-package lsp-mode
  :defer 3)
;; ...
(setenv "LSP_USE_PLISTS" "true")

The setenv call was in a different file and it wasn't obvious which file would be loaded first. Once I called it in early-init.el the issue went away

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant