search

urbit / hoon-language-server

Language Server for Hoon. Middleware to translate between the Language Server Protocol and your Urbit.
MIT License
36 stars 10 forks source link

Proposal: Use JSON channel interface for Language Server #4

Open liam-fitzgerald opened 4 years ago

liam-fitzgerald commented 4 years ago

Motivation

The language server currently uses HTTP communication to communicate between the python executable and the gall app. This is undesirable for a number of reasons, chief amongst these being the need to shoehorn bidirectional JSON-RPC semantics into a traditional HTTP request response model.

Example

textDocument/publishDiagnostics is currently updated upon save and upon a completion request. I don't think we should throw the holy water here and just bless random methods that trigger a parse. However, if we don't do this, we have no open HTTP req to send back our diagnostics upon.

textDocument/didSave blocks upon saving and this becomes an issue with larger files which has to parse the whole file before sending back a response.

Solution

The channel interface from eyre, which implements remote subscribe and poke functionality, could be used to supplement the current HTTP interface for language server. Some methods should be moved over to the channel interface and others fit comfortably into the current request/response semantics.

Example

textDocument/didChange would be implemented with a poke, as it does not need to return a value. textDocument/publishDiagnostics would be implemented with a subscription, allowing for much finer grained control of when diagnostics are calculated and sent. e.g. debouncing updates to trigger a reparse and updating when we receive a %made sign

Due to python's weird async support (read: I don't understand it) and the fact that event-stream and channels are somewhat JS specific interfaces I'm considering rewriting the python proxy in node, if this proposal goes ahead.

cc: @philipcmonk

philipcmonk commented 4 years ago

This seems reasonable.  Another approach would be to move more into the hoon side by just forwarding RPC calls directly and getting all responses through a single subscription.  This would make the Python side very small, and eventually it could be integrated into the runtime (King Haskell probably).  We have marks and parsers for RPC calls in mar/json/rpc and sys/zuse.

On Wed, Dec 25, 2019 at 3:21 AM, Liam Fitzgerald < notifications@github.com > wrote:

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub ( https://github.com/urbit/hoon-language-server/issues/4?email_source=notifications&email_token=ABKLYGDLMZB5NN6MDZFUTGLQ2M6Z5A5CNFSM4J7EMVVKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ICTHB5Q ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/ABKLYGCSZPSLSFC5FYD5ILLQ2M6Z5ANCNFSM4J7EMVVA ).

liam-fitzgerald commented 4 years ago

closing