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: addopts.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.