elm-language-server: Yet More Erratic / Broken Behaviour

Hey!

I linked a PR that I think will fix the erratic behavior and parsing errors. The code is pretty much lifted from the typescript-language-server.

The idea is basically just to keep track of the changed text for each “intermediate” state ourselves, since rootNode.text , to my knowledge, won’t be upaded until parse is called again.

I have tested this only a little and could not reproduce any of the issues that I could before. I’ll try to put in a real Elm coding session soon, to test-drive my PR under more realistic conditions 😃

Edit: I’ve been using elm-language-server with my changes for the past two days and haven’t had any more issues with bogus parsing errors 😄

Hi,

I’m also running into this issue quite often and would like to offer my help investigating it, if I can. I would say I can reproduce this very consistently in my project(s).

I’m using Helix, elm-language-server v2.7.0, and elm-format v0.8.7 - both packages installed from nixpkgs, in case that matters.

What I’ve observed so far is that it definitely seems related to formatting, at least for me:

• If I turn off format-on-save for Elm, there is no issue with the LSP at all
• If I manually format after making changes (:format in Helix), I can trigger the issue
• If I enable format-on-save, I also run into this issue quite frequently
• Also if the changes I make are already well-formatted (i.e. elm-format’s output is the same as the input), it doesn’t seem to happen - so if there are no formatting changes, there doesn’t seem to be a problem

:lsp-restart in Helix consistently fixes the issue, until I make another change and trigger it by formatting again - so it doesn’t happen for me on init.

My impression is that this happens more often when there is an actual error present, e.g. I try calling a function that doesn’t exist. However, in my testing I have seen it happen when all my changes were valid as well.

@razzeee As I said, I can reproduce this pretty consistently. Is there anything I can do to help figure this issue out? Any hints you can give me for a next step?

---

Side note

The problem seems to occur even when I configure Helix to use elm-format directly. E.g. my language configuration for Helix contains:

[[language]]
auto-format = false
name = "elm"

[[language.language-servers]]
except-features = ["format"]
name = "elm-language-server"

[language.formatter]
args = ["--stdin"]
command = "elm-format"

What this accomplishes is that Helix will call elm-format directly to auto-format the document, instead of sending a format-request to the LSP. At least I think it does… Not sure whether this is relevant, though.

I am trying helix to see if there is better lsp experience than with emacs, but I also constantly get random whole page errors.

https://user-images.githubusercontent.com/29857/223286437-2a2a8761-f7f2-4587-9a52-4bc70218856f.mov

Doing formatting like that should lead to your cursor getting displaced in some situations.

Let me try to do a release this weekend, there were some interesting sounding fixes upstream

Please try the new builds

Ok, after some further investigation I’m fairly sure I understand what is happening. The issue, I think, is indeed related to the client sending multiple contentChanges at once.

This call to getEditFromChange() gets called with the rootNode’s text, which is the same for all the change records. Since the information in later change objects assumes that earlier changes have already been applied to the document, the calculation of the startIndex and endIndex in that function probably isn’t correct. If I’m correct, this can lead to the syntax tree getting out-of-sync with the actual document. It’s especially easy for me to reproduce when newline changes are involved. At least I think that this is the issue…

I’ve attempted a (very hacky) solution and it solved the issue for some specific change sets (e.g. the one I was demonstrating earlier), but I could still get the language server into a bad state, so it’s not ready yet. It also basically amounted to trying to count the number of newlines being added and removed in previous changes and accounting for that in the calculation in getEditFromChanges(), which is probably not the best solution. I’m also not sure whether only newlines are an issue, or if one has to account for shifts in the character position as well? Ideally maybe we could call getEditFromChanges() with the updated text, but I’m not sure whether that’s possible. Might be interesting to find out how other language server implementations handle this case?

I might have some more time to look into this on the weekend, but if anyone who’s more knowledgeable about the code base than me wants to take over, that’d be great as well 😃

I still get these “whole file is covered with error(s)” with 2.7.0 and in emacs.