Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

foam_ls does not attach to foam files, exits with code 1 #13

Open
pacjac opened this issue Dec 1, 2022 · 4 comments
Open

foam_ls does not attach to foam files, exits with code 1 #13

pacjac opened this issue Dec 1, 2022 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@pacjac
Copy link

pacjac commented Dec 1, 2022

Describe the bug
LspStart exits with code 1

To Reproduce
Steps to reproduce the behavior:

  1. Install foam-language-server with Mason
  2. Configure foam_ls with minimal setup
    require('lspconfig')['foam_ls'].setup{}
  3. Open foam-file
  4. :LspInfo shows that client is configured, but not attached. :LspStart exits with code 1

Expected behavior
Client should start and attach successfully

Screenshots

Screenshot_1669887696

Desktop (please complete the following information):

  • OS: Ubuntu 22.04.1 LTS
  • Text Editor or Editor: NVIM
  • Version v0.8.0-1210-gd367ed9b2

Additional context
LspLog displays the following:
[ERROR][2022-12-01 10:34:21] .../vim/lsp/rpc.lua:733 "rpc" "foam-ls" "stderr" "/home/myname/.local/share/nvim/mason/packages/foam-language-server/node_modules/foam-language-server/node_modules/vscode-jsonrpc/lib/common/linkedMap.js:40\n return this._head?.value;\n ^\n\nSyntaxError: Unexpected token '.'\n at wrapSafe (internal/modules/cjs/loader.js:915:16)\n at Module._compile (internal/modules/cjs/loader.js:963:27)\n at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)\n at Module.load (internal/modules/cjs/loader.js:863:32)\n at Function.Module._load (internal/modules/cjs/loader.js:708:14)\n at Module.require (internal/modules/cjs/loader.js:887:19)\n at require (internal/modules/cjs/helpers.js:74:18)\n at Object.<anonymous> (/home/myname/.local/share/nvim/mason/packages/foam-language-server/node_modules/foam-language-server/node_modules/vscode-jsonrpc/lib/common/api.js:37:21)\n at Module._compile (internal/modules/cjs/loader.js:999:30)\n at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)\n"

@pacjac pacjac added the bug Something isn't working label Dec 1, 2022
@Ben-Malin
Copy link

I have also run into this bug, and I've also installed using mason.

I don't know javascript, but was able to figure out that it's an error with an out of date version of node.js
I tried updating to the latest version, but that also broke it.

Instead in installed version 14.0.0, which seems to be what was used to write it. Now it seems to work

@FoamScience
Copy link
Owner

I was planning to take a deeper look at this over the weekend;

But, I don't think the node.js version (I've tested with 14-16) matters much - it's more likely the electron version associated with it (Because the issue is with vscode-jsonrpc).

Not sure yet but try to rebuild the native modules (inside ~/.local/share/nvim/mason/packages/foam-language-server/node_modules/foam-language-server:

npm install --save-dev electron-rebuild
$(npm bin)/electron-rebuild -v [the_version_you_like]

Pick Electron's version from this table according to your nodejs version. I think this should be (ideally) executed automatically by mason when it detects native modules, but not sure.

Try the above work-around; if it still doesn't work, please send a minimal NeoVim config file which reproduces the issue; I will try to update the dependencies over the weekend anyway; might as well take a look at this.

@FoamScience
Copy link
Owner

Just a quick update on this issue; Currently the LSP server is running only with node v16.18. I have made some minor changes for things to work with 18 and 19 but apparently, tree-sitter (a crucial dependency) suffers a ERR_INVALID_URL for what it should be a local file path.

I will open an issue regarding this bug at the mainstream repo shortly; meanwhile, we're stuck with node v16.
Hopefully this will get fixed soon.

@pacjac
Copy link
Author

pacjac commented Jan 31, 2023

Please apologize the delayed reply. Downgrading node worked for me, so I'll stick with that for now. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants