Several people have mentioned problems with “missing references” in LanguageServer (LS) contexts (e.g. VSCode, eglot, lsp-mode; users of other tools please chime in). I’m finding it annoying enough to start a conversation. (Here, to get a wider audience and because it’s not clear where to file issues.)
AFAICT LS is using only the active Project.toml to determine which packages to add to a workspace context for symbol lookup (and Manifest.toml for the versions). Thus, it is necessary to add standard library packages to Project.toml for LS to work properly. A full Project.toml is routine for packages but not for projects where the base environment is inherited. I haven’t found the LS behavior documented anywhere, hence the “AFAICT”. I claim that LS should just follow the official code-loading policy.
If one follows a reference (“go to definition”) into a used package, then the third-party methods invoked from the dependencies of that package only seem to be accessible via LS if their owners were explicitly included in the original Project.toml. Is that intentional? Maybe all the packages in the Manifest should be loaded into an LS instance, or at least some sort of hooks to get them on the fly? (Contrast this with the life-saving utility of LS in the nightmare world of C++.)
[separate but related question]
In VSCode, if one adds a package to the environment, it is automatically added to the tables for an active LS instance. This does not seem to happen for the LS instances managed by Emacs. How would we fix this?