lsp: diagnostic report marking the whole file after typing `x:`

[imax9000]

What version of CUE are you using (cue version)?

$ cue version
cue version v0.16.0-alpha.1

CUE language version v0.16.0

Go version go1.24.13
      -buildmode exe
       -compiler gc
     CGO_ENABLED 1
          GOARCH amd64
            GOOS linux
         GOAMD64 v1

What did you do?

While technically correct ("the best kind of correct"), it's not exactly helpful 😅

Also, adding fields happens often during editing, and having a red border flash after every : typed is quite distracting.

#3031 is very much related, I don't know if you'd prefer to close this as a duplicate or keep for tracking UI/UX side separately.

[mvdan]

I encounter the same issue fairly regularly :) I think the LSP should have some sort of "debounce" logic too, like gopls. That way, even when syntax errors don't mark the whole file as invalid, one can type CUE and the screen isn't flashing for tens/hundreds of milliseconds as one cycles between valid and invalid syntax.

[imax9000]

Debounce might work, yes. A more complex but more accurate option would be to separate out the part of AST that is being actively edited and treat it differently. E.g., if the file evaluated successfully before - limit the scope of diagnostic report to only the edited section. And/or pretend that the edited section is valid for the purpose of assessing the rest of the file. There are a lot of heuristics that can be useful here.

As I already said in another bug:

1. do you allow insertions to transform the code from syntactically valid to syntactically invalid?

Kinda. I'd re-frame it as "Definition of 'valid' for actively edited content needs to be broader than during evaluation of complete files"

[imax9000]

But this isn't the first time this problem is being solved, and it isn't specific to cue. There should be at least a few examples of prior art.

[myitcv]

Yes another pattern that we might want to copy here is that gopls tries to "heal" the AST with up to n passes (for some n):

https://github.com/golang/tools/blob/009367f5c17a8d4c45a961a3a509277190a9a6f0/gopls/internal/cache/parsego/parse.go#L82

[imax9000]

Might be worth to also take a look at Microsoft's tsserver too (for some reason it's not listed on the LSP implementations page - maybe it never ended up migrating to LSP and still uses its own protocol 😅 )

[cuematthew]

Part of what forces gopls's approach is the fact that it shells out to the rest of the Go tools binaries because it copes with multiple different versions of Go being installed (AIUI). We don't have this constraint.

Right now, the parser barfs as soon as it hits a syntax error, and the positional information coming back from the parser isn't great. A parser that coped more gracefully with syntax errors would be welcome.