search

jeapostrophe / racket-langserver

Other
261 stars 24 forks source link

Requires X11 display on Linux #45

Open samdphillips opened 3 years ago

samdphillips commented 3 years ago

When I ssh into my workstation and attempt to use nvim with racket-langserver I get the following error:

Unable to init server: Could not connect: Connection refused
Gtk initialization failed for display ":0"
  context...:
   body of "/usr/local/stow/racket-8.0/share/racket/pkgs/gui-lib/mred/private/wx/gtk/queue.rkt"
   body of "/usr/local/stow/racket-8.0/share/racket/pkgs/gui-lib/mred/private/wx/platform.rkt"
samdphillips commented 3 years ago

It does work if xvfb is installed so running xvfb-run racket --lib racket-langserver is a workaround for now.

Runi-c commented 3 years ago

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%.

Lazerbeak12345 commented 3 years ago

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.

Lazerbeak12345 commented 1 year ago

color-textoid<%> may solve this

hunkyjimpjorps commented 10 months ago

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.

GregShiner commented 5 months ago

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.