Debugging

The fish-lsp binary ships several built-in diagnostics. Most problems can be identified with the commands below.

Tip

Short abbreviations for many of these commands are available — see Abbreviations.

First Checks

# every available sub-command and flag
fish-lsp --help-all

# build version, paths, capabilities, health
fish-lsp info

# confirm the resolved binary is the one you expect, and on your $PATH
fish-lsp info --bin
which fish-lsp

Startup Verification

The server ships with a built-in headless startup test, to verify that the server can perform analysis on a given workspace without requiring a working client connection.

This is useful for debugging issues with the server itself, or with your client configuration.

In general, a working output from the following command indicates that the server is functioning correctly:

Profiling is offered, to measure the duration of each phase in the startup process, and to help identify any bottlenecks in the server's initialization.

The --time-only flag can be used as an alias to essentially behave like --time-startup --no-warning, and will produce a more concise output:

Important

For user's who are experiencing issues with successfully configuring their editor to connect to the server, the startup verification commands above are likely the most straightforward way to confirm that the server is functioning correctly.

Typically, this indicates that a language client configuration issue is the probable cause of initial installation issues, rather than a problem with the server itself.

Checking Server Health

The server comes equipped with a built-in health check, which verifies that the minimum requirements for the server runtime are met, and also checks for out of date fish-lsp manpages + completions.

Logging

Logging is disabled by default. Enable it by pointing fish_lsp_log_file at a writable path, then tail it while a server is running:

set -gx fish_lsp_log_file /tmp/fish_lsp.log
set -gx fish_lsp_log_level debug   # debug | info | warning | error | log

tail -f (fish-lsp info --log-file)
# now reproduce the issue from your editor

Server Connects But Nothing Works

Confirm your client passes start as the argument and targets fish files:

{
  "command": "fish-lsp",
  "args": ["start"],
  "filetypes": ["fish"]
}

Then check fish-lsp info to confirm you're running the expected version. See Client Configurations for editor-specific examples.

Inspecting Parse Output

Given a file like:

/tmp/example.fish test input
function greet --argument-names name
    set -l greeting "Hello"
    echo "$greeting, $name!"
end

greet World

We could inspect how the server is parsing and analyzing it with the following commands:

Add --no-color to any of the three --dump-* flags to strip ANSI colors, e.g. when piping the output somewhere else.

You could also pipe valid fish shell as stdin to any of the above --dump-* commands.

cat /tmp/example.fish | fish-lsp info --dump-parse-tree -

Source Maps

To debug the bundled server code with readable stack traces:

set -gx NODE_OPTIONS '--enable-source-maps --inspect'
$EDITOR ~/.config/fish/config.fish

Note

Source maps might not be included in the build you are using (decided by the package manager or installation method used)

You can confirm if source maps are included by checking the output of:

fish-lsp info --source-maps --check
fish-lsp info --source-maps --check output

If you are seeing bundled js locations in the stack traces, then try testing with a build that includes source maps instead (i.e., building from source with yarn build:bin or yarn build:npm, or downloading a standalone release)