Currently, when an update request is received, the TextEdit is computed and applied to an open WorkspaceDocument through an LSP client. The changes are subsequently propagated to LSP server, and go through all DocumentBuilder steps (including model reconciliation, changes computation and pushing an update). When the calculated updates are pushed through LMSDocumentBuilder, there are a 300ms delay designed to accumulate also subsequent changes (given the document is modified manually by the user) to not clog the subscription channel with too many update messages.
However, this delay should be disregarded, when an update comes from LMS Update API, since there will be no immediate text edits following.
Currently, when an update request is received, the TextEdit is computed and applied to an open WorkspaceDocument through an LSP client. The changes are subsequently propagated to LSP server, and go through all DocumentBuilder steps (including model reconciliation, changes computation and pushing an update). When the calculated updates are pushed through LMSDocumentBuilder, there are a 300ms delay designed to accumulate also subsequent changes (given the document is modified manually by the user) to not clog the subscription channel with too many update messages. However, this delay should be disregarded, when an update comes from LMS Update API, since there will be no immediate text edits following.