# scheme-lsp-server
## Introduction
** EXPERIMENTAL **
A LSP (Language Server Protocol) server for Scheme.
## Goals
This software aims to support several Scheme implementations. To achieve this,
the code is designed to contain as much logic as possible in R7RS Scheme,
separating implementation-specific code in different directories.
Currently only CHICKEN 5 and Guile are supported.
*Note*: this code is still in an early development stage and the API may change.
Design suggestions are welcome.
## API
```
[parameter] (lsp-server-log-level)
```
A symbol to control the server's verbosity. It can be either 'error, 'warning,
'info or 'debug.
```
[function] (lsp-server-start tcp-port-number [tcp-error-port-number])
[function] (lsp-server-start/background tcp-port [tcp-error-port-number])
```
Start an LSP server listening on `tcp-port-number`.
`start-lsp-server/background` starts the server on a new thread and returns it.
Optionally one can provide a `tcp-error-port-number` to receive logging messages
from the server. If not provided, all error messages are directed to
`(current-error-port)`.
## Supported Features
|
Guile |
CHICKEN |
Find signature |
X |
X |
Find documentation |
X |
X |
Autocomplete symbol |
X |
X |
Jump to definition |
X |
X |
## Notes to specific implementations
### CHICKEN
The implementation for "jump to definition" is for now quite limited. I wrote
a ctags-inspired code for CHICKEN that scans the project files for definitions.
Additionally, the user can set the environment variable `CHICKEN_SOURCE_PATH`
to a directory containing the installer's source, so that the server can
provide information to internally defined functions.
In the future we can refine this solution to be more "project-aware". Ideas
are welcome.
### GUILE
We rely on Guile's runtime to get information such as function definition
location. This allows fetching symbols restricted to the user's project.
On the other hand, an LSP client has to load the corresponding
files in the runtime so that this information becomes available.
## Ideas on extending support to other Schemes
Here are some ideas on how add support to other Scheme implementation without
increasing much code complexity:
### decide which build system to use.
Currently we use two build systems:
`chicken-install` with its egg definitions, and `autotools` for Guile. Ideally
we should come up with a solution that can be used across all supported
implementations. Possible candidates are Snow or Akku. Alternatively we could
consider extending the existing `autotools` based scripts.
### move more code to the common session.
Ideally we would leave to the implementation-specific files only code needed
to provide programming-language features (find signature, documentation etc.).
This is unfortunately still not the case, since the server relies on
functionalities not provided by the RnRS standards, like JSON (used by our
JSON-RPC library) and TCP sockets.
It would be extremely helpful if those bits are solved by separate libraries
or SRFIs. Guile's version for JSON-RPC already uses SRFI 180, so I would suggest
to adopt it by other implementations.
### write more (and portable) tests.
For now all the testing is done using a CHICKEN specific library
(see 'tests/run.scm'). Their should for one side be improved to cover other
parts of the library, and possibly be written in a portable way to allow
ironing out bugs in other implementation.