WieeRd/auto-lsp.nvim

fix: reduce false positive of executable checks

Closed this issue · 5 comments

Problem

Server availability check is done by running vim.fn.executable() on the executable names extracted from the cmd field of lspconfig. However, this yields false positives on the server's availability in some cases. Here's a non-exhaustive list of those problematic executable names.

dotnet
java
nc
node
npx
perl
python
python3

These are not executable names of each language server, but a generic scripting language or package manager executables (and also nc, the netcat TCP client). They are used to launch the actual server module / files, e.g. python -m <module> or java -jar <server.jar>.

Knowing Python is available on the system tells nothing about the actual server's availability.
The failed to start error messages from lspconfig caused by these false positives are quite annoying.

Solution

It is very hard to check the actual availability of these servers.
Instead, they should be filtered out, classified as "uncheckable", and disabled by default.

Marking as "Uncheckable"

Servers that cannot be started without user configuration are marked as false in the server_executable mapping.
So to distinguish from that, uncheckable servers will be marked (or unmarked?) as nil.

Filter out the Uncheckable

How? Unfortunately manual labor. But I do have an idea for a heuristic to reduce my work.

Tasks

  • fix: disable uncheckable servers by default
  • feat: add opts.enable_uncheckable_servers
  • feat: filter out uncheckable servers
  • Server executable being a language name (e.g. python) is a red flag.
  • Language executables are often named the same as the language itself.
  • Vim filetypes are often named the same as the language itself.
  • Conveniently enough, I have already generated a mapping of various filetypes.

Conclusion: Compare the values of server_executable with the keys of filetype_servers.

Some languages actually do come with a language server as a subcommand.
e.g. nu --lsp, dart language-server --protocol=lsp

This would cause false negatives from above heuristics.
I will have to review each uncheckable servers and whitelist them manually.

Some languages actually do come with a language server as a subcommand.

There are far, far more languages like this than I expected.

aiken
bzl
dafny
dartls
erg_language_server
futhark_lsp
gleam
koka
mint
nushell
superhtml
templ
uiua
vls

All the newer languages and DSLs seem to do that, language server built into the compiler/interpreter as a subcommand.

And it is very likely to happen again when a new DSL is added to lspconfig. I need to reconsider this heuristic if I don't want to review every PR to lspconfig in fear of this happening and having to whitelist them every time.

Reverted to blacklisting each executable name.