Fork me on GitHub
#lsp
<
2022-02-28
>
lassemaatta09:02:52

clojure-lsp does not seem to do any caching when stub generation is enabled, right?

lassemaatta09:02:39

but it seems that as a workaround I can first use :generation to generate the stubs and then disable auto generation and use :extra-dirs to include the previously autogenerated stubs.

ericdallo01:03:36

yes, that could work, but as a workaround indeed

ericdallo01:03:11

Does the stub generation is taking too long or you? it's done async after startup so it should not affect that much

lassemaatta05:03:11

It did not feel very async, as the LSP startup was stuck on "analyzing stubs" for a long time (most likely that 76 seconds you can see in the logs), before finishing the initialization. (now that I look closer at the log, I can see that the stub generation and "refreshing clojuredocs" seem to happen concurrently) During that time my cpu usage was very low, which seems odd.

lassemaatta05:03:53

I'm using lsp-mode , Emacs 29.0.50, gnu/linux, clojure-lsp 2022.02.23-12.12.12 + clj-kondo 2022.02.09.

ericdallo18:03:19

@U0178V2SLAY you are correct, for some reason I didn't make the stub generation async, I'll double check if it was on purpose or we can change it to be async

lassemaatta18:03:37

No worries, it’s easy to work around :)

ericdallo18:03:37

I took a look and it seems it could be async, which may be better for a faster startup indeed, I'll change it for next release, thanks for the report

👍 1
lassemaatta18:03:22

Perhaps another nice-to-have feature to consider is if lsp could eg. hash the source class files and (re)create the stubs only if the cached hashes differ. But this is most likely a very low priority thing.

ericdallo18:03:33

yes, this is something I'd like to add in the future, a hash per file, it would help a lot avoid analyzing same files