Repository navigation
Investigate tower-lsp for use as the server backbone #1
Description
Activity
As per ebkalderon/tower-lsp#284 it seems that scheduling based on mutability has not been solved. I'm a big fan of other design choices they've made however, so there's likely room for a fork.
Uncertain if I didn't notice this before or if this was recently added the lsp spec but there's the possibility of sending a ContentModified error and canceling a pending request, so potentially room for handling request ordering / execution without messing with the scheduler in the concurrent read case (e.g. diagnostic generation)
if a server detects an internal state change (for example a project context changed) that invalidates the result of a request in execution the server can error these requests with ContentModified. If clients receive a ContentModified error, it generally should not show it in the UI for the end-user. Clients can resend the request if they know how to do so. It should be noted that for all position based requests it might be especially hard for clients to re-craft a request.
Reacted by Oliver Mannion
As mentioned in astral-sh/ruff#271 using an established framework for working with the language server protocol would improve maintainability