Installation instructions

[jpaju]

Hey! 👋🏼

First of all, thanks for building a LSP for fish!

I tried to install the LSP by downloading the binary (fish-lsp-macos) from the 1.0.0 release. When the client (I'm using Helix editor if that matters) sends the initialize message to the LSP, it crashes and dumps this to stderr:

Aborted(Error: File '/**/fish-lsp/node_modules/web-tree-sitter/tree-sitter.wasm' was not included into executable at compilation stage. Please recompile adding it as asset or script.)\n
failed to asynchronously prepare wasm: RuntimeError: Aborted(Error: File '/**/fish-lsp/node_modules/web-tree-sitter/tree-sitter.wasm' was not included into executable at compilation stage. Please recompile adding it as asset or script.). Build with -sASSERTIONS for more info.\n
Aborted(RuntimeError: Aborted(Error: File '/**/fish-lsp/node_modules/web-tree-sitter/tree-sitter.wasm' was not included into executable at compilation stage. Please recompile adding it as asset or script.). Build with -sASSERTIONS for more info.)\n
/snapshot/fish-lsp/node_modules/web-tree-sitter/tree-sitter.js:1\n
(function (exports, require, module, __filename, __dirname) { var Module=void 0!==Module?Module:{},TreeSitter=function(){var initPromise,document=\
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            \n
\n
RuntimeError: Aborted(RuntimeError: Aborted(Error: File '/**/fish-lsp/node_modules/web-tree-sitter/tree-sitter.wasm' was not included into executable at compilation stage. Please recompile adding it as asset or script.). Build with -sASSERTIONS for more info.). Build with -sASSERTIONS for more info.\n
    at abort (/snapshot/fish-lsp/node_modules/web-tree-sitter/tree-sitter.js:1:5612)\n
    at /snapshot/fish-lsp/node_modules/web-tree-sitter/tree-sitter.js:1:6661\n
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n
\n
Node.js v18.5.0\n 

I can see that the error is about missing a tree sitter wasm executable. Should there be some additional installation steps to get this working?

[ndonfris]

Hi @jpaju

So the binaries I included earlier today have only been tested on linux locally. In the most recent changes I've merged into master, they mostly pertain to providing a better method of building the wasm file (which might have caused the error you are seeing). I do not have much experience with using pkg to create a binary from a node environment, so I would currently not recommend relying on them to install the project. If you are experienced with using a tool like pkg to distribute node binaries, I could definitely use some help.

From the error message you provided, I believe installing the project from source would resolve those issues.

git clone https://github.com/ndonfris/fish-lsp.git
cd fish-lsp
yarn install
yarn setup
fish-lsp --help # would indicate that the project successfully built 

From research I've conducted across other language servers using tree sitter, the currently accepted approach requires building the wasm executable locally when the project is installed. This is done in the file: scripts/build-fish-wasm.sh. If you're having issues after building the project still, could you confirm if running ./scripts/build-fish-wasm.sh properly outputs the tree-sitter-fish.wasm file in the project root. Since the wasm file is required as dependency, the project can not be compiled without a tree-sitter-fish.wasm file for the parser to read. I outlined one potential solution to hopefully remove the need for using wasm here. I'd be happy to discuss removing it all together in that thread too, if you're interested in collaborating on the project.

For helix specific configurations, I believe you should be able to use the fish-lsp start command to directly listen to any language client that is using stdio to communicate. The command fish-lsp (and fish-lsp-macos in your current case), are just the entry point from the shell process into the ./out/cli.js. If you can successfully build the 'out/**/*.js ' directory from a command like yarn tsc -b, you can provide the executable file path ~/fish-lsp/out.js to helix. I've done it in several different neovim language clients. While, I haven't used helix, I did find the following documentation, that looks like it should support the following configuration in languages.toml:

[[language-server.fish-lsp]]
command = "fish-lsp"
args = ["start"]

[[language]]
name = "fish"
auto-format = false
language-servers = [ "fish-lsp ]

Here's a very similar setup from the kickstart.nvim client I setup this morning.

[jpaju]

Hey! Thanks for the extensive instructions 🙏🏼 Finally had some time to try to build the LSP from source. There was quite a many issues that I was able to solve, and also some that I wasn’t able to solve. I configured the LSP to Helix and was initially able to start it, here is the configuration btw:

[language-server.fish-lsp]
command = "node"
args = ["<path-to-project-root>/out/cli.js", "start"]

I’m using a M2 Mac and running yarn setup hanged indefinitely on two different machines I tried it. I was able to resolve this by running the commands (yarn install & build-wasm & compile) in setup.sh manually. I had to run build-wasm a couple of times to actually create tree-sitter-fish.wasm.

Next issue was that the LSP expects fish executable to be available in path /usr/bin/fish , which is not the case for me. One solution would be to make the path configuratble or, even better, resolve the fish executable from the user’s PATH . I was able to resolve this by changing the hardcoded path in exec.ts.

Another thing I noted at this point is that the LSP sends error messages as window/logMessage about missing a log file (<project-root>/logs.txt). This doesn’t (to my understanding) prevent the LSP to work, just something I noticed.

The last issue I encountered was that once the client sends initialize request ({"jsonrpc":"2.0","method":"initialize","params":{ … }) to the LSP, it doesn’t receive response to this. As per LSP specification, the client cannot proceed (send any other requests before the server has responded to the initialization. I think this is because for me the call to FishServer.create in cli.ts hangs indefinitely. I added some logging to debug this, but wasn’t able to precisely pinpoint where (initializeParser(), initializeDocumentationCache(), initializeDefaultFishWorkspaces() or initializeCompletionPager(logger)) the issue is.

Once we’re able to resolve this, I’m happy to help with the packaging. I’m somewhat familiar with Nix and I’m thinking configuring the packaging with it. What do you think?

[jpaju]

I digged a bit deeper and was able to pinpoint that promises returned by execCmd and execEscapedCommand in exec.ts never resolve. Do you have any ideas how to debug this further?

[ndonfris]

Great to hear the feedback and future interest in the project.

I currently planned on making the project more configurable and easier to install, hence the recent additions to cli.ts.

I did some digging of my own, upon your initial feedback, and found that I could use the fish-lsp binary momentarily (like quickly running a hover request) but it would eventually crash/panic. It looked like there was some other language servers that were also having similar issues in helix. In neovim, this does not happen from any client I have tested, so I am unsure directly what is causing the helix based issue. I did some research Friday on other possible client & server connection protocols that could be used (as this might help solve the helix based issue).

Here's some questions I have in your findings:

• Out of curiosity, what is the binary path for the shell on macos?
• What node version are using, and what specifically is the errors you saw in the scripts/build-fish-wasm.sh file?
  • I got the idea for building the wasm file from the bash-lsp's scripts/upgrade-tree-sitter.sh file. The tree-sitter-cli npm package on my machine has released a new version where build-wasm is no longer supported on my machine. Was this related to the issue you mentioned here?
• Could you try the prior version of the exec.ts file and see if that offers any improvements?
  • I believe the reason I changed it to the current version, was because the previous version creates a subprocess in the current shell. This means it could potentially be slower than the newer version, since all of required information will needed to be passed to the subprocess.
• When you mention that the fish-lsp hangs indefinitely, what do you mean by this?
  • When running the fish-lsp start command, it should not provide any input or output to the terminal. This is because the current protocol reserves stdin/stdout for the client/server communication. The logs.txt file should be where requests are stored (if the server is running requests should be shown here). One way to test the the server could be done by having two windows open:
    • tail -f logs.txt in one window
    • opening helix ~/.config/fish/config.fish in the other.

    When I did this, I could see the requests were being made, but the client was not able to properly use the output they produced.

  • Furthermore, this is why I mentioned that I wanted to improve the actual cli.ts output, because this is not what new users would probably expect when running the start command.
  • One approach that might be drastic, would be to implement the server to work on a client like monaco. From what I can tell, properly implementing a working client/server connection in this approach would universally work across any editor. (this is something I'll be looking into to make the project more widely accessible)
• As you can probably tell, the exec.ts contains lots of unnecessary code. I plan on refactoring this in the future, but getting node to run code in the shell was a very difficult task for this project. The main issue, has to deal with escaping the input to run the shell command. There is the option of running the string escape command before running the exec.ts functions. From my own testing, I still ran into issues with the node process, not being able to properly run run the exec function from child_process. Some options we could look into for future improvements come to mind:
  • using an external library to run the shell commands
  • editing the command to suppress stderr output 2>/dev/null
  • finding a more efficient way to run the shell commands from child_process

As for what I currently think the issue is stemming from:

• The server takes too long to index, and helix considers it be a hanging process before it can properly index all the system files, and the client/server connection. It takes about 2 seconds to index 700 fish shell files on my machine. The tree-sitter-node discussion and refactor would significantly speed this up.
• The server might be logging non json output to stdio which could be causing the crashing. This would explain why I could get it to work momentarily, before crashing.
• Helix actually has a bug, that is causing the server to crash. This is probably not the case, but I'm interested to see if you could check out a working client and test it in neovim-nightly.

helping you pinpoint the specific issue further

Editing the src/server.ts file and commenting out capabilities or handlers that the server will try to provide will get you going in the right direction.

• most of the initialize capabilities.
• (better method) comment out the register connection handlers instead.

I'd recommend commenting out providers, like this:

// these will be necessary 
connection.onInitialized(this.onInitialized.bind(this));
connection.onDidOpenTextDocument(
    this.didOpenTextDocument.bind(this)
);
connection.onDidChangeTextDocument(
    this.didChangeTextDocument.bind(this)
);
connection.onDidCloseTextDocument(
    this.didCloseTextDocument.bind(this)
);
connection.onDidSaveTextDocument(
    this.didSaveTextDocument.bind(this)
);
// connection.onCompletion(this.onCompletion.bind(this));
// connection.onCompletionResolve(
//     this.onCompletionResolve.bind(this)
// ),
connection.onHover(this.onHover.bind(this))
// comment out all other providers 
// connection.console.log("FINISHED FishLsp.register()"); // TRY COMMENTING THIS LINE OUT SINCE IT ALSO COULD BE CAUSING THE ISSUE

[ndonfris]

As for packaging in nix, I think that'd be a great idea if we could get it working.

I'm currently looking into yaserver's projects setup, to hopefully improve the node release. This might also help me get a web-socket version working, which helix could use (as seen in the netcat example.

[shaleh]

Fellow Mac user who just set up the lsp this morning. The useful binary ended up in ~/.yarn/bin which was not in my PATH. Adding that made fish-lsp work just fine. I never ran yarn setup. yarn install was sufficient.

I can run fish-lsp from my shell:

$ fish-lsp --version
1.0.4

Helix sees the LSP.

$ hx --health fish
Configured language servers:
  ✓ fish-lsp: /Users/seanperry/.yarn/bin/fish-lsp
Configured debug adapter: None
Configured formatter: fish_indent
Binary for formatter: /opt/homebrew/bin/fish_indent
Highlight queries: ✓
Textobject queries: ✓
Indent queries: ✓

And my languages.toml does in fact match what was shared earlier:

[[language]]
name = "fish"
language-servers = [ "fish-lsp" ]

[language-server.fish-lsp]
command = "fish-lsp"
args= ["start"]

[shaleh]

https://github.com/zed-industries/json-language-server might be another approach.

[ndonfris]

Good find! Feel free to fork and PR if you end up porting the script to this project.