# 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.
Change 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.
```
[procedure] (lsp-server-start/stdio)
```
Start an LSP server listening on stdio.
```
[procedure] (lsp-server-start/tcp tcp-port-number)
```
Start an LSP server listening on `tcp-port-number`.
## Supported Features
|
Guile |
CHICKEN |
Find signature |
X |
X |
Find documentation |
X |
X |
Autocomplete identifier |
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
Most of the current implemention relies on Geiser. We include the corresponding
Scheme files in our repository (git submodules was discarded to simplify
packaging and automatic installation from LSP clients.
## 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.