You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Investigate using Language Server Protocol (LSP) to provide the Rose Edit server.
Overview
In order to implement the Rose Edit GUI editor as a web app we will require a few interfaces for:
Opening/Saving the document.
Synchronising the document between the editor and the server.
Validating the document.
Registering/actioning commands (e.g. macros).
Rather than implement these interfaces ourselves we could choose to use Language Server Protocol (LSP) which provides interfaces for all the above and more.
On the surface this is a highly attractive option which would give us advanced support for configurations in text editors. We would develop a LSP server to power the GUI, but get text editor integration for free.
No need for us to design our own bespoke types/interfaces.
Existing Python server implementation (pygls) complete with concurrency model.
Add support to any text editor with an extension.
Standard Abuse
However, our usage of LSP for the GUI would form a slightly funky pattern because there are two differences to the normal arrangement:
The "Rose Edit" GUI does not have filesystem access so the server would need open/save interfaces.
The document which we would be synchronising would differ depending on the client.
The server would need to synchronise the raw text file with text editors with all validation results using line numbers (e.g. 42).
The server would need to synchronise a derived JSON document with the GUI with validation results using configuration paths (e.g. [namespace:foo=bar]).
This diagram summarises the differences:
In theory these differences could be overcome, the server might need to acquire open/save interfaces but it should be doable.
Questions
Would we need to implement open/save interfaces or can LSP do this?
Normally the editor (client) opens the file and synchronises it with the server.
Is there a pattern for doing this the other way around or an obvious way of doing it?
How would we manage the difference in the document being synchronised?
The GUI wants JSON the editor wants plain-text.
How does this impact validation etc?
Can we work around this?
How would we package the Rose Edit server as a LSP extension e.g. with VSCode?
LSP servers are usually JS although there are a few Python ones kicking around.
How would we package the LSP server to ensure the required dependencies installed / env activated?
The text was updated successfully, but these errors were encountered:
Investigate using Language Server Protocol (LSP) to provide the Rose Edit server.
Overview
In order to implement the Rose Edit GUI editor as a web app we will require a few interfaces for:
Rather than implement these interfaces ourselves we could choose to use Language Server Protocol (LSP) which provides interfaces for all the above and more.
On the surface this is a highly attractive option which would give us advanced support for configurations in text editors. We would develop a LSP server to power the GUI, but get text editor integration for free.
pygls
) complete with concurrency model.Standard Abuse
However, our usage of LSP for the GUI would form a slightly funky pattern because there are two differences to the normal arrangement:
[namespace:foo=bar]
).This diagram summarises the differences:
In theory these differences could be overcome, the server might need to acquire open/save interfaces but it should be doable.
Questions
The text was updated successfully, but these errors were encountered: