The language server's handling of didChange notifications involves an adaptive debounce timing based on the average re-parse time for the current document. If parses are quick, we shorten our debounce time. If parses take a while, we lengthen our debounce time.
Potential improvements:
- Consider the user's typing speed as well. If edits are sparse, we can afford to shorten the debounce a bit more
- As it's written currently, the debounce time will never drop below 100ms. For very small files, this is excessive, and in many cases we ought to be able to drop as low as 20ms or 30ms without issue
- The current logic for calculating debounce timing is inlined in the didChange handler. It should be moved / better organized
The language server's handling of didChange notifications involves an adaptive debounce timing based on the average re-parse time for the current document. If parses are quick, we shorten our debounce time. If parses take a while, we lengthen our debounce time.
Potential improvements: