Open bashful-strix opened 2 years ago
LSP spec is difficult to follow, at least for me. Indeed the textDocumentSync property can be either a dictionary or a numeric value but wether the client sends the didSave notification to the server depends on if the server capabilities include the "save" property inside the "textDocumentSync" property:
/**
- If present save notifications are sent to the server.
- If omitted, the notification should not be sent. */ save?: boolean | SaveOptions;
By configuring the server to send didSave notifications if textDocumentSync is numeric larger than 0 I believe we are breaking the protocol and may affect other LSP server implementations.
On the other hand it seems the support for numeric values is for backward compatibility so maybe on previous versions of the protocol was implicit that didSave was sent if this value was either 1 (FULL) or 2 (INCREMETAL). If this is the case then your suggested fix should do the work.
Other approach would be to ask purescript-language-server developert to update their server to implement a more recent version of the protocol (e.g. 3.16).
Yeah, I found the spec pretty unhelpful. I did consider raising this on purescript-language-server
, but thought that since it was documented in the spec it should be raised here instead. I'm happy to raise it as an enhancement there as well, though.
Like I said, that fix was pretty crude and was simply what appeared to fix it while I was debugging, though I'm very unfamiliar with both vimscript and the LSP spec. When I get some time I'll dig around some more; given that the didSave
event seems to be separate from didChange
, it might be something else going on, though given that all other aspects of ALE and the language server are behaving correctly, it does seem to be something about the save/change communication.
After doing some digging through the implementation of coc.nvim
and vim-lsp
, and going back through the spec, I believe numeric textDocumentSync
should be supported.
The latest spec says
- property path (optional): textDocumentSync
- property type: TextDocumentSyncKind | TextDocumentSyncOptions.
indicating that both the enum (numeric) and object values are valid for textDocumentSync
.
Assuming I found the correct parts of the code, vim-lsp and coc.nvim both account for this situation as well.
Information
VIM version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Dec 17 2021 18:32:08) macOS version - x86_64 Included patches: 1-2671, 3402, 3409, 3428, 3489
Operating System: MacOS Monterey 12.2.1
What went wrong
According to the spec, language servers are allowed to return a number for the
textDocumentSync
capability, rather than a dictionary of specific values (thepurescript-language-server
does this for instance), but this change prevents these servers running on save events.After much digging (hard to track down since the server and ALE are all working correctly. including omnicomplete, etc.) I have rather crudely fixed this locally with this patch
I'm afaird I don't know enough about vimscript to say if this is the right way or to update tests...
Reproducing the bug
textDocumentSync
value (eg.purescript-language-server
):ALEInfo