unable to register with lsp or run via cask

[mooseyboots]

i'm trying to get elsa going for the first time and i'm unable to.

my config (also using straight):

(use-package lsp-mode)
(use-package elsa)
(use-package flycheck-elsa)
(add-hook 'emacs-lisp-mode-hook #'flycheck-elsa-setup)
(setq flycheck-elsa-backend 'cask) 

with this elsa-lsp-register isn't loaded, so i manually loaded elsa-lsp and elsa-lsp-core.

then i call elsa-lsp-register, but nothing happens. the error message (which doesn't display) in the cond in that function suggests i need cask/eask. i have cask installed, and it is in the path for emacs shell.

i have never used lsp before, and it's unclear to me how cask is involved. so perhaps i need some more config beyond cask being on my shell path?

if i follow the cask approach from the readme, with a project that already uses Cask, after adding elsa as a dep then calling cask install, then cask exec elsa $FILE, i get a pile of errors in the shell command output, starting with Debugger entered--Lisp error: (cl-no-applicable-method elsa-type-get-return nil).

[Fuco1]

Hi @mooseyboots thanks for the report. It is still a bit rough to run this thing :/

Elsa does not run in your Emacs session, it always runs as a separate Emacs process. Your personal config is therefore never used or loaded by Elsa. You can only run Elsa over a project (you can turn your config in a project if you want though).

First, make sure you have latest version of all the dependencies, I've been submitting a lot of patches to ansi, async and trinary. Easiest way is to delete .cask and reinstall everything (or try cask update but it never works for me)

Your Cask file should look something like this:

(source melpa)
(source gnu)

...

(development
 (depends-on "elsa")  <-
 ...)

Run cask exec-path and make sure that the elsa directory is there, something like

/home/matus/.emacs.d/projects/Elsa/.cask/28.2/elpa/elsa-0.1.0/bin

(the part after .cask is important).

Then from the root directory (where Cask file is) you should be able to use cask exec elsa file.el.

To use it as LSP, you need to run the elsa-lsp-register as you did. After this, lsp-mode should start elsa lsp in the scope of the Cask project. That project must use Cask and have elsa as a dependency. So you can't run it anywhere. Once the lsp server is started, it will also only analyze the files in the project where it was started.

You need cask (or eask, or something else) to provide this process separation. Elsa never runs in your Emacs session because it could get its environment polluted by the "current session". It runs in its own process to be sandboxed.

[mooseyboots]

thanks a lot for explaining all the steps!

i did understand that i had to use cask, i was just calling it from emacs using (shell-command).

removing .cask and reinstalling all the dependencies helped. i got it running.

i'm a bit wigged out though, it returns hundreds of false positives. it seems like it doesn't handle autoload declarations, so any functions called from other files in the same package aren't recognised. it thinks (y-or-n-p) calls always return nil, or (when my-pkg-var checks also.

anyway, interesting for me to have a first try with lsp. baby steps.

[Fuco1]

In package code you can't really use autoloads. Each file must require all its dependencies. Elsa scans the requires and follows the entire tree up to the point where there's no more requires left (even many levels nested).

Many built-in functions are not annotated yet so those just return some generic types, see #22, #147. Macros don't work yet, see #205, #196.

At version 0.1.0 I'm expecting it to be generally usable, you can track this in the corresponding milestone. Thanks for trying it out. Out of curiosity, are you a package developer or are you trying to analyse your .emacs.d?

[mooseyboots]

thanks for the further details.

i'm the maintainer of mastodon.el (https://codeberg.org/martianh/mastodon.el). it's my only cask project i think. i was curious to try it out to see if it might alert me to some bad coding habits, which it did. i found that all the info level issues were real, and all the error/warning ones were false (or rather there were too many for me to tell).

[Fuco1]

Thanks for the project reference. I'm always interested in trying this out on real projects out there. I'm very biased towards implementing features useful for analysis of my projects, mostly Elsa itself :grin:

Currently I'm working on adding support for macros which should resolve a ton of the false positives as macros very often introduce unknown variables to the scope which Elsa just ignores currently.