Clojurians Log v2

has anyone here found that clojure-lsp / lsp-mode in emacs significantly slows down slurping and barfing expressions with smartparens?

@rickmoynihan This can be related to

company-idle-delay 0.5

@borkdude what do you have it to set to?

0.5

Also update to the newest, there might have been some improvements around this

ahh great upgrading seems to have made a big difference!

thanks! 🙇

ah it could also be that lsp-mode is no longer connecting hmmmm

anyone here know how to debug lsp not connecting anymore after an upgrade?!

Running

$ clojure-lsp
{}

https://clojure-lsp.github.io/clojure-lsp/troubleshooting/

however nothing appears in the log

@rickmoynihan the troubleshooting should be self explanatory otherwise we can improve it, but if the executable is working we need to understand why it's crashsing

check the *clojure-lsp-stderr* buffer if has any thing relevant

otherwise we need to check the log

usually it's on /tmp/clojure-lsp.*.out

Yeah I went through the troubleshooting section but nothing seemed to help

the emacs buffers for logs etc didn’t seem to exist either

what is the error you receive on emacs?

no visible error — just LSP[Disconnected] in the mode line

and no lsp features

what happens when you M-x lsp

aha! lsp--path-to-uri: Symbol's function definition is void: -compose

(I was running M-x lsp-mode)

https://github.com/emacs-lsp/lsp-mode/issues/2615

TLDR update your dash.el package and everything should work

ok that seems to work

thanks a million! 🙇

You're welcome 😉

hmm now get apply: Cannot open load file: No such file or directory, lsp-ui

I suggest you re install your packages

That’s what got me here 😆

but yeah I’ll try reinstall again…

ok seems to be working

🙇

Hi, I think https://github.com/clojure-lsp/clojure-lsp/blob/master/src/clojure_lsp/feature/file_management.clj#L119 might be the piece of code in charge, it expects a range of changed characters. I will see if I can get LSP running locally so that I can confirm and submit a PR, it might be tomorrow though.

Yes, it is, that was changed recently, probably we are having some race condition on there, we need to check how vim is sending the didChange texts

I think the issue might be simpler: NeoVim doesn't send a start/range at all because it's sending the entire text. So replace-text is getting nil values in line, col, end-line, end-coland throws the NPE

It could be indeed, but even so I think it should send the position according to the LSP spec

I did a small POC locally and indeed it throws an NPE, and of course the fix is trivial -- I will try tomorrow to run LSP locally so I can verify that this is indeed happening and add a test.

/**
 * An event describing a change to a text document. If range and rangeLength are
 * omitted the new text is considered to be the full content of the document.
 */

from the spec

Seems like a NeoVim bug though.

Oh, missed that, cool 🙂

The client should respect the incremental sync but it seems like it doesn't... but I guess that yeah supporting that on the server is easy enough...

Thanks!

yes, probably handling the didChange as full text when the range is not present seems a valid approach

recently updated lsp, and it seems like unused vars no longer highlight, but if i do a lsp-lens-show i can see it has 0 references

am i missing something config-wise?

We didn't change anything related to that, check this section to see if it works for you: https://clojure-lsp.github.io/clojure-lsp/troubleshooting/#wrong-diagnosticslint

hm, no dice… :thinking_face:

pretty sure this is just me misunderstanding how the unused checking works

clj-kondo will look for private unused vars, and this wasn’t a private var. unfortunately whoever wrote the code im working on was not very judicious in their application of adding private metadata

I don't get it the error, do you have a small sample?

sure,

(ns foo)
(defn bar [])
(defn- baz [])

So clj-kondo should report only the unused private function baz, right?

yes

but i could swear globally unused publics highlighted awhile back

i may be mistaken

oh yeah

we used to have those for public functions before clj-kondo integration (2020 december)

i guess i understand why it’s not a clj-kondo thing, but it is useful when removing dead code

for instance, of course you don’t want your public API fns highlighted, but then again, i would assume those have a test…

yeah, for sure, it's something we lost when using clj-kondo, but I think we could implement it

need some hammock time though how to do it

https://github.com/clojure-lsp/clojure-lsp/pull/357

Thanks! I added some suggestions, looks good though

Thanks for the suggestions, they look obvious in retrospect 🙂

If you could capture somewhere the format that the emacs lsp client sends the changes I might be able to provide a test that covers both cases... But not tonight.

Any more action needed on my part? I think testing on Emacs is the blocker here. I've setup NeoVim to run my local fork of clojure-lsp so if something like this comes up again it'll be easy to validate.

Sure, for a range this is a sample:

(ns foo)

(let [a 1
      b 2]
  (+ a b))

[Trace - 04:30:39 PM] Sending notification 'textDocument/didChange'.
Params: {
  "textDocument": {
    "uri": "file:///home/greg/dev/nu/zakarum/postman/integration/aux/init.clj",
    "version": 55
  },
  "contentChanges": [
    {
      "range": {
        "start": {
          "line": 4,
          "character": 7
        },
        "end": {
          "line": 4,
          "character": 8
        }
      },
      "rangeLength": 1,
      "text": "c"
    }
  ]
}

(ns foo)

(let [a 1
      b 2]
  (+ a c))

I can test manually the PR tonight (couple of hours), if everything ok, I can merge it

@borkdude lsp already supports info lint, green color

nice. how does it do the local highlighting?

But I think we don't use on clojure-lsp for any feature

the local highlighting is a custom thing for highlighting on lsp-mode side

ok, we could do an info-level "warning" maybe

enable it by default, and if people complain offer a way to disable it

yes, I think it's the best option

continuing the convo from #clj-kondo: eh, i’m not 100% sure on highlight v warn. i’ll say i’m biased because i was used to a warning-like indicator in the old clojure-lsp. I think lens is neat, but where I found the previous underline helpful was when i was cruising around in a file and it was like “oh look, someone left some dead code here…”

the info lint is just like the warn lint but green not yellow

oh, that sounds great

https://github.com/clojure-lsp/clojure-lsp/issues/359

yay! big thanks!

maybe a better name {:unused-public-var {:level :info}}

so you can add more stuff to it and also :exclude stuff

maybe using a regex, namespace, fully qualified var

yeah, that looks perfect 🙂

I think I saw that pattern somewhere 😛

;)

carve has a .carve/ignore file: https://github.com/borkdude/carve so you can interactively add it to the list of ignored vars

@devn 🙂

I would put "var" instead of "variable", that is the proper name or clojure vars

but looks nice!