Unfortunately it's outdated, we recently migrated outside lsp4j and that exception is no more

But you can just skip it, TBH I think I'll remove that from the troubleshooting

What exactly is not working?

well, it is really the only thing in trouble shooting

hard to say, I don't have much experience with the lsp stuff

I am trying to use eglot (emacs lsp client)

and it seems to launch clojure-lsp, and then things timeout

(lots of requests getting sent to clojure-lsp from what I can see, but no responses)

It's not the only thing on troubleshooting, there are more sections. Right, I'm a lsp-mode user but I know @U976F1AR2 uses it with eglot

There is not that much people using it with eglot AFAIK but it should work

Are your clojure-lsp updated?

I just run the install script

clojure-lsp 2022.10.05-16.39.51
clj-kondo 2022.10.05

Looks correct

Is eglot pointing to the correct path of clojure-lsp?

I am running on it on a pretty big project

A start would be to test in a sample project

yeah, clojure-lsp is launching, and that is the only clojure-lsp I have installed

Alright, you can enable server trace logs, but before you can check server logs

It's on the troubleshooting how to check server logs

yeah, I do have logs, and there is output in there, nothing that looks abnormal, I bumped up the eglot timeouts already, but maybe I need to bump them up even more for the first run on a large project

Oh, yeah, for bug projects the really first time should take more time, 1-2mins if a huge project

@U0NCTKEV8 My 2 cts: if you want to get started, it might be better to use lsp-mode which all of the clojure-lsp maintainers are also using and after a while migrate to eglot if you're more comfortable with the existing setup

With lsp-mode there is a progress bar during initialize, I think eglot doesn't have that

I had it at 5 minutes and just bumped to 10 🙃

Hum, I doubt clojure-lsp takes that much, you can confirm on logs too

Clojure-lsp server logs say exactly how much time it took to start

it looks like clojure-lsp is crashing, because it is sending progress analyzing project updates, and I can see stuff in the logs, then sometime after 100% of that, everything goes quiet and there is no clojure-lsp process running anymore (checked via ps)

ah, ok, maybe missed the clojure-lsp process still running, but I've got it running with --trace now

lots of chatter in the log

huh, so it is running and seems to be fine, but doing a rename, the server log says it is sending back the edits, but elgot is saying it got a timeout

Trace may help know if clojure-lsp is receiving and send logs

Hum, sounds like client issue indeed

eglot

it doesn't help that I keep wanting to call it elgot

I'd suggest trying another client like vscode or lsp-mode

elgot

eglot is got mainlined into emacs

already?

not in a release yet I don't believe

I know, still missing lots of stuff lsp-mode has

@U0NCTKEV8 a tip when installing lsp-mode: when you find it too noisy, you can disable stuff. This is my current config https://github.com/borkdude/prelude/blob/2a951dfa28d8b7c535430cc86ead7ccff18c43a3/personal/init.el#L374-L391 e.g.

lsp-headerline-breadcrumb-enable nil

(I also disabled linting but this is because I run clj-kondo separately, the latest dev version)

On the other hand, I found lsp-lens-enable t worth enabling (which shows the number of references and tests next to each var). I'm not sure if that is enabled or disabled by default

the thing is, if I wanted lsp-mode I would have installed lsp-mode 🙂

Something of this may be useful for you/apply even for eglot: https://emacs-lsp.github.io/lsp-mode/tutorials/clojure-guide/

it seems like some how rpc reply messages are being dropped

Maybe add a log on eglot side when receive a msg or something

looks like jsonrpc is complaining about some message it gets from clojure-lsp at start up, and then maybe refusing to parse more messages after that

could it be that clojure-lsp is printing something to stdout while it should print something to stderr?

@U06F82LES has also been using eglot I think

(https://twitter.com/pesterhazy/status/1577217343012614145)

hard to tell, I need to figure out how to get in the middle between emacs and eglot and see what is actually going on

I disabled kondo linting in clojure-lsp, and that appears to have gotten rid of the jsonrpc startup error, but operations still all timeout

hah!

I added the setq in https://emacs-lsp.github.io/lsp-mode/tutorials/clojure-guide/ and everything blinked to life

What setq exactly?

the one that starts with setting gc-cons-threshold

this is intense, a lot of information suddenly getting throw at me

Oh right, IMO that should be the default value, I have no idea why emacs doesn't change that..

With eglot there I hope they start to realize those changes :)

Not that it’s available with eglot, but those setq settings are checked by lsp-doctor, correct?

> this is intense, a lot of information suddenly getting throw at me now I really want to see a screenshot :)

@UKFSJSM38 now that eglot is https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg01609.html, we probably need to spend more time ensuring it’s operating smoothly. I’ve had good luck with lsp-mode, but there are likely to be more eglot users soon

@U04V15CAJ I've using just emacs without even cider and any of that stuff, just getting docstrings in the minibuffer confuses and amazes

but I still cannot turn kondo on in the clojure-lsp config without it breaking things

@U07M2C8TT agreed, there are know eglot issues I know like not going to definition of external files

@U0NCTKEV8 my experience was that having both flycheck + flycheck-clj-kondo and also lsp-mode trying to do thing with flycheck didn't work for me. So I disabled lsp-mode's flycheck completely for this reason

Not sure how to do that with eglot

M-. doesn't work for stuff in jars (I know, I know, I haven't had a working M-. setup in years anyway)

Opting to use clj-kondo’s flycheck over lsp-mode’s flycheck is worth trying but be aware that you lose a diagnostic that way… specifically unused-public-var, which flags vars that are defined but never used. @U04V15CAJ I think you also prefer using them separately so you can more easily see the very latest lint from your local build of clj-kondo, rather than waiting for clojure-lsp to bump its clj-kondo version, correct?

When I navigate to first , emacs points me to clojure source in .emacs.d/workspace/.cache - not sure why it doesn't open the .jar file (like CIDER does) but it does navigate to something for me

@U050SC7SV https://github.com/clojure-lsp/clojure-lsp/issues/1329

I'm not using :unused-public-var as lens-mode already gives me that information. And yes, I'm running the always latest dev version of clj-kondo so I can actually see what I'm doing

Yep, lens-mode is a decent substitute, but I like having the unused vars in the flycheck errors list

M-. on first drops me in a new file called "core.clj" in /var/foo/home/kevin/.m2/repository/org/clojure/clojure/1.11.1/clojure-1.11.1.jar::clojure/

elgot must just not handle paths into jars I guess, the '::' thing

I think @UKFSJSM38 was planning to change lsp-mode so that it doesn’t use the .emacs.d/workspace/.cache directory @U04V15CAJ

@U0NCTKEV8 would you try adding :dependency-scheme "jar" to your clojure-lsp config.edn?

After changing it, it’s probably best to blow away your .lsp/.cache and restart clcojure-lsp

I will try that

clojure-lsp supports two “dependency-scheme”s which are essentially formats for the URLs it returns. The URL you pasted, with the :: looks like it’s the “zipfile” scheme, which eglot almost surely won’t understand. The “jar” dependency scheme should use !/ instead of :: (among other differences) which perhaps eglot will understand. Unfortunately the “zipfile” scheme is our default, though we’re talking about changing that. If this works, it’s a change that should really be incorporated upstream into eglot

also wonky, in a slightly weirder way

and for some reason the new empty file it jumped me into has had an ns decl inserted at the top

(ns ws.billing.member.file:.var.foo.home.kevin..m2.repository.org.clojure.clojure.1.11.1.clojure-1.11.1.jar!.clojure.core)

That’s one of the clojure modes, possible clojure-lsp, “helping” you fill out the ns name based on the new file’s name

ah, I see, when the new file opened eglot asked if the server was allowed to edit the file, and the server helpfully inserted a namespace decl to match the crazy location the file ended up in

I suspect you’re running into this https://github.com/joaotavora/eglot/issues/661

The last comment on that Issue was 44 seconds ago, so I don’t think you’re alone

Also a reminder… when you’re done debugging, don’t forget to turn off tracing—it’s a common performance problem

already did

@U976F1AR2 opened that issue, he's a clojure-lsp and eglot user (and a coworker :p), I bet he can help too with his eglot knowledge

It'd be really nice to make all eglot users use jar dependency or we change the default @U07M2C8TT

@UKFSJSM38 what I don’t understand is why we need to jump through all these hoops. Emacs already understands jars and their files. Try opening a jar file from your .m2 directory. Is it just that Emacs needs a special URI format that we’re not serving?

s/Emacs/vanilla Emacs/

To follow up on this … it appears that arc-mode.el provides https://github.com/emacs-mirror/emacs/blob/55eabe96c92aaee336a7ed4cce4d5b4186c9eeeb/lisp/arc-mode.el#L651, which is a dired style view of an archive. Because jar files follow the zip file format, archive-find-type https://github.com/emacs-mirror/emacs/blob/55eabe96c92aaee336a7ed4cce4d5b4186c9eeeb/lisp/arc-mode.el#L736 the jar as a zip. This gets translated in the mode line into “Zip-Archive”. From the dired view, you can navigate to a file. That’s as far as I’ve gotten. I’m not sure yet how it unzips the file, or whether that’s something tools like eglot and lsp-mode could hook into

It unzips the jar under the hood and get the content to a temp buffer, that's how cider does as well

I think emacs only works with jar deps scheme, I can't recall if zipfile works

> emacs only works with jar deps scheme It sounds like Emacs itself, with its default packages, doesn’t work with either scheme. That is, if you just tell it to open a file inside a jar using either scheme, it thinks you’re talking about a new file. > It unzips the jar under the hood That’s what I’m reading too. It’s not clear to me whether external tools could use the functions it defines to open files in jars, or if you have to first open the jar in dired

AFAIK the mode helps providing functions, check cider-find-var it uses a similar o rthe same function that does that

Yep, you’re right, cider uses a helper from arc-mode.el. I’m going to report that on the eglot ticket. Maybe it’ll help them too.

https://github.com/clojure-emacs/cider/blob/20debc82696bdd5ce807618d02665b92a4274492/cider-common.el#L396

I am reporting back from https://github.com/joaotavora/eglot/issues/661 Eglot does not set the "jar" dependency-scheme setting, but even if it is set it has even more trouble understanding "jar" format than the "zipfile" format . This is because the jar: uri contains a nested uri, so it needs to be parsed twice. So setting the dependency-scheme from eglot won't really help this problem as is. I will at least try to get a change pushed to eglot so that it can dispatch the jar scheme properly. Even with that in place, more code will have to be loaded up into emacs to make it understand how to open URLs inside jar archives. More on that to come!