Open samdphillips opened 3 years ago
It does work if xvfb
is installed so running xvfb-run racket --lib racket-langserver
is a workaround for now.
Looks like this was brought up before in #18. The fundamental cause is that the racket server relies (heavily) on the editor class text%
provided by racket/gui/base
, and even just requiring this package causes it to try and initialize a display, even if one won't actually be used. I'm doubtful that there's anything we can do here without basically re-implementing all of the navigation and paragraph features from text%
.
I'm not sure if this is a good idea at all, but I've been brewing on it and wanted to share some thoughts.
We could make drracket depend on this library for the code analytics features and make this library not depend on drracket anymore. (in essence swap the dependency direction to ensure we don't need x11 or libgdk for what is supposed to be a headless service)
But tbh that's a drastic change, and now probably isn't the time for such a thing.
color-textoid<%>
may solve this
I'm trying to use the workaround with xvfb-run
in a Github Codespace, but the server immediately crashes five times and then Magic Racket gives up.
We could make drracket depend on this library for the code analytics features and make this library not depend on drracket anymore. (in essence swap the dependency direction to ensure we don't need x11 or libgdk for what is supposed to be a headless service)
I second this. This is how LSP is supposed to be done. Unfortunately, DrR doesn't actually use LSP AFAIK since it predates the release of LSP standard. It seems like what they are doing is decoupling the language services from DrR and building the LSP implementation on top of that.
If the racket core team were to make this change though, it would have some pretty awesome benefits by fully adopting the LSP standard. But, it is quite a big ask.
When I ssh into my workstation and attempt to use nvim with racket-langserver I get the following error: