I have a setup where my tooling is sandboxed in a way that may require providing a custom path to some of the binaries. In the case of vale, when I start the LSP I get this server log:

initialized!
configuration changed!
Vale CLI not installed!

I tried to specify the path to the CLI binary in both the binary and settings lsp Zed settings fields, but to no avail.

"lsp": {
  "vale": {
    "binary": {
      "path": "/<absolute-path-to-vale-dir>/bin/vale"
    },
    "settings": {
      "valeCLI": {
        "path": "/<absolute-path-to-vale-dir>/bin/vale"
      }
    }
  }
}

Do you think the extension would need to handle this in addition to the current setup?

Thanks for writing this zed extension, I have also tried to do this myself but I did not quite succeed and you beat me to it 😅

But I seem to be getting some errors in the language server logs when hitting ⌘+. to fix the spelling issues.

Here the logs:

initialized!
configuration changed!
stderr: thread 'main' panicked at src/server.rs:318:61:
stderr: called `Option::unwrap()` on a `None` value
stderr: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Sadly it seems to be an issue with the vale language server itself. Have you also experienced this issue?

On a fresh install, vale-ls was failing to start per Zed logs.
I had to manually add execution permission to the binary to fix it

chmod u+x "/Users/me/Library/Application Support/Zed/extensions/work/vale/vale-ls-v0.3.7/vale-ls"

Specs

Zed: v0.145.0 (Zed Preview)
OS: macOS 14.4.1
Memory: 16 GiB
Architecture: aarch64

The extension.toml should ideally register the language server for all languages listed in https://vale.sh/docs/topics/scoping/#formats