Thanks for this!

I tried with two lsp, in the next days I'll be trying more (Note: I'm using a Linux distribution that symlinks /home to /var/home):

• Go (gopls): The server starts and it processes a few messages like initialize and textDocument/didOpen but eventually returns an error when responding to the workspace/configuration[2]:

{"message":"Error loading packages: err: chdir /var/home/selenil/dev/go_devcontainer: no such file or directory: stderr: "}

When Eglot tries to do more work the server just keep replying with the same error. At some points this happens:

{"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"uri":"file:///workspaces/go_devcontainer/../../../../var/home/selenil/dev/go_devcontainer/main.go","diagnostics":[{"range":{"start":{"line":0,"character":8},"end":{"line":0,"character":12}},"severity":2,"source":"go list","message":"No active builds contain /workspaces/go_devcontainer/../../../../var/home/selenil/dev/go_devcontainer/main.go: consider opening a new workspace folder containing it"}]}}

And from there, the server keeps running but it ignores interactions with:

{"jsonrpc":"2.0","error":{"code":0,"message":"no views"},"id":3}

• Gleam (built-in lsp): This one starts fine and I can do all the usual things and the server doesn't crash. However, some features are not reflected on the actual buffer. For example, I can run code actions and those messages will be processed successfully (Eglot even displays the "Edit successful!" message), but the actual contents of the file had not changed. Flymake don't display warnings or errors even if the code is invalid and the server has send a message with the exact error. xref finds correct definitions when doing jump-to-definition, but they pointed to invalid paths. Autocompletion and hover documentation work without issues.

Diggin into the messages I found that Eglot sends incorrect uris. For a file in /var/home/selenil/dev/my_project/src/app.gleam, Eglot sends: {"uri":"file:///var/home/selenil/var/home/selenil/dev/my_project/src/app.gleam"} so I guess that's why edits are not reflected in the file.

Can we somehow advise eglot to add the docker exec automatically if appropriate. The solution with devcontainer-eglot-server is somewhat clunky

In some early tests I did advising eglot--connect when in devcontainer-mode works fine.

Diggin into the messages I found that Eglot sends incorrect uris. For a file in /var/home/selenil/dev/my_project/src/app.gleam, Eglot sends: {"uri":"file:///var/home/selenil/var/home/selenil/dev/my_project/src/app.gleam"} so I guess that's why edits are not reflected in the file.

That's interesting. Not sure if it's related to the $HOME symlinking of your distribution. Maybe you can debug this by messaging out path, truepath, relative and in-container in devcontainer--path-to-uri-advice.

Another issue that I came across in real life testing is, that maybe not all LSPs can be expected to run in the container. So we need some way of deciding if we do the path uri translation or not depending on if the LSP server is running inside or outside the container.

I found that most of my issues were caused due to my distribution symlinking $HOME. The problem is that devcontainer--root returns paths starting with /home while in other places paths start with /var/home/, so when we get to this line the relative path is wrong: (relative (file-relative-name truepath (devcontainer--root))). Manually removing the /var prefix from the paths makes it work again.

Aside from that, the other issue I have is that Flymake doesn't report the error diagnostics in the UI. This doesn't seems to be related to the $HOME symlinking. I will dig into it when I have some time, but maybe we need to advice Flymake too.

Aside from that, the other issue I have is that Flymake doesn't report the error diagnostics in the UI. This doesn't seems to be related to the $HOME symlinking. I will dig into it when I have some time, but maybe we need to advice Flymake too.

I was doing some debugging and it turns out that this issue is actually caused by the $HOME symlinking of my distribution. Currently I just patched the code to remove the /var prefix from the paths and with that all works fine.