[nickelpro]

If you do not understand how the underlying language server is configured, what the input and outputs are, how it operates, you will run into errors you are unequipped to deal with.

Some languages are more severe than others on this. For example, in C++ your editor is not going to be able to make efficient use of the clangd language server without intervention from the programmer to understand and configure it. On the other hand, for Python the Pyright LS will be mostly fine without additional configuration.

[lstodd]

What's so special about clangd?

I only had to silence a couple of unneeded warnings specific to codebase I was working with, which took under five minutes and that only because I finally got annoyed enough. Otherwise it took zero configuration (this was Kate though, but it doesn't matter, there is no clangd-specific default config there).

[nickelpro]

Basically that clangd needs an accurate compilation database to consume, which isn't a requirement for other language spaces.

[lstodd]

What is an "accurate compilation database"?

If you mean that dependencies better resolve = project better be in a mostly buildable state or they complain of undefined stuff that's true.

[nickelpro]

The compilation database[1] given to clangd needs to be complete, understood by the clangd argument parser, and capable of producing a build.

This starts to hurt bad when the compiler producing the build is not clang. If you try to use a compile database describing C++20 module compile lines for GCC, clangd will choke badly. If you're using MSVC flags that clang-cl hasn't been taught yet, clangd falls over. If you're using CMake to produce the compile database, it will leave out synthetic targets from the database and you will see errors because clangd cannot find the interfaces described by those targets. If you're not using CMake you need to configure bear or ninja or whatever to produce a compilation database for you. Etc, etc.

[1]: https://clang.llvm.org/docs/JSONCompilationDatabase.html