Problem:
As in #24, it's impossible to extract `uri` variable from
`notify_back`, but sometimes we want to do this
Solution:
Add `method get_uri = uri` to notify_back
Problem:
As in [#22], we want to shut down our LSP server correctly.
That means we should close the pipe and end process after an exit request.
This require proper `shutdown : unit -> bool` function passed
to `Jsonrpc2.Make.run` which returns `true` after
the server received an exit request.
Right now both exit and shutdown requests are setting
LSP server's internal var `_quit` to true. It's very intuitive to
use this var in `shutdown`, but we can't do it, since in this case
the server would stop receiving new messages right after the
shutdown request, despite the fact according to the LSP specification
it had to wait the exit request.
Solution:
Instead of `_quit : bool` use
```
status : [ `Running | `ReceivedShutdown | `ReceivedExit ]
```
and suggest
```
shutdown () = s#get_status = `ReceivedExit
```
in docs for `Jsonrpc2.Make.run` and in the templete/example.
Problem:
If an LSP client sends a request with "params":null instead
of omitting the params field or smth like "params":{},
decoding error appears.
Solution:
Replace `null` value for "params" to `{}`
Problem: There was a misunderstanding when implementing this: batch
processing should not return responses individually, but rather return a
list with batch responses. This will require some further logic to group
such responses in order to process them in sequence.
Solution: We return those methods to being unhandled.
Problem: Linol can only send notifications from the server to the
client, but not requests.
Solution: The solution was inspired by Haskell's `lsp` package. We first
maintain a `server_request_handler_pair` data structure which represents
some server request and its associated response handler. Now
`notify_back` may take these fields and use it to actually handle a
request and its response. Changes to `notify_back` are propagated
throughout `server.ml`.
On `jsonrpc2.ml`, we refactor the notification and request handlers so
that we may handle the response and batch response handlers and batch
call as a courtesy. For a response, we keep a hash table that tracks an
ID to the `server_request_handler_pair` in other to be able to call the
handler that was associated with the response. After we get such
response (indexed by the server request's ID), we remove it from the
hash table to prevent a memory leak.
Since the server needs to keep track of the server request IDs, I added
a mutable `id_counter` in order to generate a fresh LSP ID (using
`fresh_lsp_id`) for every outgoing request.
For debugging, if we error while decoding a JSON, I now print the
exception too.
