Idle timer for lsp-on-change

[topisani]

Accumulate the change-event parameters in lsp-on-change and limit them with an idle timeout. Also make sure these events are then sent before sending any other requests/notifications. lsp--send-did-change does the actual sending if any changes are lined up.

This was sparked over at emacs-lsp/lsp-ui#45, and seems to be the best solution overall, since the didChange events are sent extremely frequently by default. This is a nice place to do performance tuning.

We are still testing it a bit with cquery, but it would be great if someone could try it out with some other servers!

[alanz]

We used to have this, but the problem is that there is no way to combine multiple changes into a single change message that is meaningful to the LSP server.

[alanz]

See #112

[yyoncho]

@alanz

We used to have this, but the problem is that there is no way to combine multiple changes into a single
change message that is meaningful to the LSP server.

Why do we need to merge them in single document change message? Can we collect the N changes and send N document change notifications without the need to merge them into single one.

[alanz]

Can we collect the N changes and send N document change notifications without the need to merge them into single one.

@yyoncho what is the benefit of this running on a timer? Vs sending them as they happen, as now.

[yyoncho]

@alanz Hm, I believe that you are right - it won't benefit a lot(theoretically if the server has delay it will increase the chance to skip rebuilt). I think that the changes can be reavaluated to work as they are performed on the original document as you have mentioned in #112

[yyoncho]

Denying the PR as it is as per #239 (comment) .