Send textDocument/didChange for groups of edits, not one per each change.

[yyoncho]

Possible improvement for lsp-mode as per https://github.com/joaotavora/eglot .

[yyoncho]

I did performance testing using php/rust/java and it seems there is no any performance implication related to sending not grouping the updates. Since VScode is sending the updates one by one, it looks like the server are optimized to do not perform build or any heavy operation on key press but they already group the updates on server side. In my tests the fontlock was taking 50% of the CPU time while the LSP code less than 1%.

@MaskRay what do you think from CCLS point of view, do you rebuild on each didChange notification?

[alanz]

An earlier issue #112 deals with trying to batch the changes, with the conclusion that it is not possible to do it based on the change notification process in emacs.

So it is up to the server to "batch up" changes, and only do the diagnostic processing per batch.

For example, in the haskell-ide-engine we wait for 350ms without a change message before triggering diagnostics.

[yyoncho]

@alanz

I wonder whether it will pay off to implement the other option listed in #112

Adjust the edit locations so that they all refer to the original document, so they can be applied according to the specification.

My conclusion for now is like yours - Won't fix - due to the fact that the servers do buffer the updates and also the sending itself is fast (~1000 in second on 5 year old PC).

[yyoncho]

I am closing this for now. Later, we may do complete performance testing and reevaluate this decision.

[MaskRay]

Yeah this should be done on the server side and AFAIK ccls clangd haskell-ide-engine have implemented debounce.