Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-03-15

Channels

#lsp
<
2021-03-15
>
dpsutton16:03:24

things got a bit out of sync when i added a require to a namespace. is there a way to have lsp reparse the current file? I had to resort to restarting the workspace

borkdude16:03:09

@dpsutton Making an edit in the relevant files will have the same effect probably

dpsutton16:03:09

yeah. i edited and saved and it didn't like the state it ended up in. My evidence for that is the highlighting of words under point was nonsensical. Like it would highlight the third and fourth letters of a function and didn't recognize the other call sites

dpsutton16:03:29

restarted the workspace and it got it right, highlighting the entire token and highlighting the other usages of the same

snoe16:03:19

Yeah I've seen this too recently. I'm pretty suspicious of using this partial changes api @ericdallo https://github.com/clojure-lsp/clojure-lsp/blob/master/src/clojure_lsp/feature/file_management.clj#L107 I think there's a lot that can go wrong there.

borkdude16:03:13

it sure is hard to get it right and since ericdallo didn't mention my name in that commit, I take no responsibility for it :P

borkdude16:03:29

maybe it should be under an experimental flag in the config

snoe16:03:17

i think so, I'd rather aim for stability by default and sacrifice speed of edge cases.

dpsutton16:03:02

is there a way to reanalyze current file? kinda just kick clojure-lsp? Or is the best workaround at the moment to restart the workspace?

borkdude16:03:03

the current file should be re-analyzed on every edit, I think?

borkdude16:03:33

but it could be related to the problem discussed above with partial snippets that are sent over the wire

borkdude16:03:54

if you edit files outside of your lsp environment, those edits might not be seen by lsp?

ericdallo16:03:47

@dpsutton kill the file buffer and reopen should fix it for now

dpsutton16:03:12

that makes sense. thanks @ericdallo

ericdallo16:03:17

re-editing should not fix since if one edit go out of sync, all other probably will go wrong too

orestis16:03:27

@snoe it was handling ranges for a long time, the change was to add full text support.

ericdallo16:03:47

I could not reproduce the edit sync error, if you have a repro we could improve that

orestis16:03:05

The neovim client is always sending the whole text. Perhaps the Emacs client could be configured to do the same?

borkdude16:03:08

I think it might happen if you git pull some changes ?

ericdallo16:03:24

@orestis actually we used to use the full text since the beginning, I changed recently with the help of @borkdude to use the range edit changes

borkdude16:03:40

no no, I have nothing to do with it :P

snoe16:03:44

there's a capabilities negotiation so the server can tell lsp-mode it only support full-text afaik

ericdallo16:03:45

but it seems there is some corner cases that the doc goes out of sync

ericdallo16:03:58

yes, but lsp-mode support both full and range edits

ericdallo16:03:29

full-text edit can end in a a really poor performance on large buffers

borkdude16:03:30

@ericdallo I suggested above to make this feature experimental and opt-in using a flag in the .lsp/config.edn - thoughts?

ericdallo16:03:57

yes, we could go this way, but that will probably make it hard to get the corner cases

ericdallo16:03:54

Not sure if we should try to find the issue and fix it, We are already using it and it works for most cases (I use it daily and could not repro the out of sync issue yet)

ericdallo17:03:50

the incremental didChanges increased the performance on medium/large buffers a lot, I think we should try to make that happen

borkdude17:03:15

Wasn't that performance issue only manifesting when you had some delay set to 0?

ericdallo17:03:07

That made the performance worst because of a lsp-mode limitation with completion, but besides that, with this feature, every change you do in a big buffer is more smooth

snoe18:03:04

https://github.com/clojure-lsp/clojure-lsp/blob/master/src/clojure_lsp/feature/file_management.clj#L136 this seems suspicious - there's no check here that the current version is older than what's being applied and I can't reason through the async nature of analyze-changes but I would be surprised if there's no issue there. And I think debouncing with a change api is big no-no

ericdallo18:03:11

the debouncing help us now call clj-kondo on every change if user input a lot of characters

ericdallo18:03:28

and AFAIK they come in a fixied order from client

ericdallo18:03:49

you can try input multiple 1 s in a single line in a buffer to repro that

dpsutton19:03:53

if you type "abc" does it coalesce all of the changes into "abc" or is it possible you'd see "ab" and then "c"?

ericdallo19:03:47

it should join all changes to abc correctly with my tests, maybe is some specific corner case

ericdallo19:03:21

my tests I inputed dozens of characters to check if any race condition could cause trouble, and everyting worked great

ericdallo19:03:49

I suspect you fell into some specific corner case

rafaeldelboni20:03:52

Hey I dunno if is related to the issues being discussed today, but I'm getting a strange crash error after I updated today 🧵

rafaeldelboni20:03:56

After using a little bit the server crashes all functionalities stop working I need to force a lsp server restart.

ericdallo20:03:01

It seems to be a issue indeed, do you have a code repro of when this exception happens?

rafaeldelboni20:03:32

It happens randomly I was in a fixture test file with a lot of defs

rafaeldelboni20:03:36

Just editing the file and saving

rafaeldelboni20:03:48

I just caused a random typo error and now the server crashed with this error: [1;31mjava.lang.Exception[m: [3mUnexpected EOF. [at line 53, column 1][m

ericdallo20:03:17

the issue happens during the parse of a clj-kondo lint findings, but I still not sure when it happens

ericdallo20:03:27

a minimal repro would help a lot

ericdallo20:03:39

do you have the piece of code that caused the crash? including the typo

borkdude20:03:15

also moving config aside .clj-kondo and .lsp/config.edn could help diagnose

rafaeldelboni20:03:28

Just created a file and started typing random code and this error happened

ericdallo20:03:25

Odd, I can't reproduce it, I'll keep trying to understand it

ericdallo20:03:51

what's you clojure-lsp --version ?

rafaeldelboni20:03:13

clojure-lsp 2021.03.14-23.22.46
clj-kondo 2021.03.03

rafaeldelboni20:03:16

oh wait maybe is my java version

rafaeldelboni20:03:29

openjdk version "11.0.10" 2021-01-19
OpenJDK Runtime Environment (build 11.0.10+9)
OpenJDK 64-Bit Server VM (build 11.0.10+9, mixed mode)

ericdallo20:03:39

how did you install clojure-lsp?

ericdallo20:03:48

the native versions don't depend on java

ericdallo20:03:09

I don't think it's a related to java

borkdude20:03:32

did you try to move your configs aside?

ericdallo20:03:19

BTW the exception from the first log is different from the next log 🤯

rafaeldelboni20:03:33

yeah is random

rafaeldelboni20:03:38

I will move now

rafaeldelboni21:03:52

yeah still happening without the kondo files

rafaeldelboni21:03:08

[1;31mjava.lang.Exception[m: [3mUnmatched delimiter: } [at line 40, column 1][m

ericdallo21:03:54

@UMMMKKADU the second log, the issue happen on didOpen that is when client send to server that a new file was opened in the client editor, and we can see that is a StringIndexOutOfBoundsException https://github.com/clojure-lsp/clojure-lsp/blob/master/src/clojure_lsp/feature/file_management.clj#L25 when is parsing the uri -> namespace

ericdallo21:03:35

could you send the json log between client and server to check what your client is sending? I supposed you use vim, not sure how to get that log in vim lsp clients

rafaeldelboni21:03:31

@U11EL3P9U knows, I never know how to do this

borkdude21:03:47

Maybe Rafael can try an older version from before the incremental diffing?

ericdallo21:03:33

what was the previous version that it was working @UMMMKKADU?

dharrigan21:03:51

CocCommand workspace.showOutput

ericdallo21:03:33

@borkdude from that log the didChange incremental change is a consequence of the didOpen exception, not the cause

rafaeldelboni21:03:33

I don't remember I can try rollback some versions

rafaeldelboni21:03:12

@ericdallo if you type (defn asdljkfjkasldfkjlsdaf) in a clojure file save and try to go to definition you don't get this error?

ericdallo21:03:25

No, I don't. I'm starting to think that the client is sending some messy range? that's why the request and response log could help

rafaeldelboni21:03:33

nothing relevant comming out 

## versions

vim version: NVIM v0.4.4
node version: v14.15.3
coc.nvim version: 0.0.80-98a0c6db19
coc.nvim directory: /home/delboni/.local/share/nvim/plugged/coc.nvim
term: xterm-256color
platform: linux

## Log of coc.nvim

2021-03-15T18:15:33.518 INFO (pid:31644) [services] - registered service "languageserver.godot"
2021-03-15T18:15:33.520 INFO (pid:31644) [services] - registered service "languageserver.clojure-lsp"
2021-03-15T18:15:33.522 INFO (pid:31644) [services] - clojure-lsp state change: stopped => starting
2021-03-15T18:15:33.540 INFO (pid:31644) [services] - registered service "eslint"
2021-03-15T18:15:33.542 INFO (pid:31644) [plugin] - coc.nvim 0.0.80-98a0c6db19 initialized with node: v14.15.3 after 93ms
2021-03-15T18:15:33.547 INFO (pid:31644) [language-client-index] - Language server "languageserver.clojure-lsp" started with 31655
2021-03-15T18:15:44.639 INFO (pid:31644) [services] - clojure-lsp state change: starting => running
2021-03-15T18:15:44.644 INFO (pid:31644) [services] - service languageserver.clojure-lsp started
2021-03-15T18:15:45.105 INFO (pid:31644) [attach] - receive notification: showInfo []

ericdallo21:03:25

this is not the correct log

ericdallo21:03:38

It should be a log with the content of the request and response from client <-> server

ericdallo21:03:46

with the json body

dharrigan21:03:11

I'll do a PR

thanks 3
ericdallo21:03:59

@UMMMKKADU it'd be nice if you could test other versions until we find the version that introduced the issue And find the logs as well 😅

rafaeldelboni21:03:29

Thanks for the help I will do some tests with older versions

👍 3
rafaeldelboni21:03:01

2021.03.06-17.05.35 is working fine here, I will do some more tests tomorrow

ericdallo21:03:05

Ok LGTM @U11EL3P9U, it'd be better if it makes sense to another vim user, could you check that PR later @UMMMKKADU?

rafaeldelboni20:03:54

Just a followup, using the previous version all is working fine here.

ericdallo20:03:33

@UMMMKKADU I'll release a new version tonight rollingback the incremental text changes until we fix it, maybe it should fix your issue

🎉 3
rafaeldelboni13:03:25

Just installed this one right? 

clojure-lsp 2021.03.16-20.28.06
clj-kondo 2021.03.03

👍 3
rafaeldelboni13:03:38

I will use it today and report here

rafaeldelboni22:03:25

I worked all day with the new version and zero problems thanks

ericdallo22:03:36

Glad to hear 🙂

dpsutton22:03:09

does clojure-lsp watch for changes to .lsp/config.edn or require a restart?

ericdallo23:03:56

It requires a restart