resolve relative paths for configuration paths

[dotcarmen]

in my os project, i use a submodule for the zig repo to

1. avoid hard-coding paths to local git directories
2. include all commits from ongoing PRs (i have a DEV branch which merges all such PRs)
3. avoid loading build.zig from the zig repo, since it's unnecessary and causes my project's build.zig to fail to build (since i use zig 0.14 to build my project, only diverging with std)

it'd be nice to support this automatically with editor configurations. for example, in the latest commit of my os project, i included a zls.json that sets the zig lib dir to the one in the submodule.

[dotcarmen]

note that the os project is my only project currently that uses anything besides standard zig 0.14. it's gotten pretty annoying having to mv ~/Library/Application\ Support/zls.json{,.bak} and back (and subsequent restarting of the LSP) every time i want to work on my os project, so i'm just trying to squash some config issues :)

[Techatrix]

Using --config-path to setup per-project configuration is something I do not wish to promote as it would make people more inclined to use a zls.json instead of using LSP workspace config (ZLS Docs, LSP) which is supported by most editors.

To give an example of how this could look like in Zed, the following .zed/settings.json could be made to work:

{
  "lsp": {
    "zls": {
      "settings": {
        "zig_lib_path": "./path/to/zig/lib"
      }
    }
  }
}

An absolute path already works. Relative paths should only be supported with workspace configuration.

Also, Zed has Direnv integration which can be used to set the ZIG_LIB_DIR environment variable. This has the advantage that it also applies to running zig from the terminal. Unfortunately this appears to not affect the output of zig env which means that ZLS will also not be affected. I will look into resolving that.

I see that the ZLS docs do not explain how to setup per-project configuration so I am currently looking into updating them. I would suggest to subscribe to #1687 which tracks this issue.

[dotcarmen]

I do not wish to promote as it would make people more inclined to use a zls.json instead of using LSP workspace config which is supported by most editors.

May I ask why you have this preference? that encourages duplicating configuration options (.zed/settings.json, .vscode/settings.json, .sublime-project, etc) in files that are typically omitted from source control, resulting in a higher barrier to entry for 3rd party contributors. It also means that contributors have to manage a workspace configuration for every editor they use in every project that uses non-standard configurations, which is a very unpleasant experience.

preferring zls.json would also resolve the "most editors" part of your comment - all editors with any form of lsp support would automatically support zls.json, regardless of whether the editor has configuration options available for zls. It also leaves support for other build systems, for example Bazel and Nix, which prefer vendoring dependencies over using tools available in the user's environment. (for example, at least in Bazel it's common to generate a compile-commands.json - and for Rust, rust-commands.json - that utilizes the specific Bazel-provided toolchains, which then gets used by LSPs)

further, as mentioned in the issue you linked (#1687), the default behavior in neovim for over 6 months now is to handle a workspace zls.json (overriding the global one if the local one is present); there's already precedent and support in the community assuming workspace zls settings are an option

[Techatrix]

May I ask why you have this preference?

1. Workspace configuration works across many editors and is part of the protocol but zls.json is ZLS specific. It's easier for users to learn a single config system that works for all of their LSPs than each one having their own.
2. Internally, zls.json and workspace configuration do not cooperate well. It's two config system having little knowledge of each other. I had to deal with various issues because of how ZLS merged these independent config sources.
3. If zls.json were to support being looked in per-project, we are signing us of to develop an even more complex config management system in ZLS than we already have. Can sub-projects also have a zls.json? How are they combined with other zls.json files? What should relative paths in the zls.json be relative to? The ZLS process cwd or the directory containing the zls.json? And how does all of this integrate with LSP workspace configuration and workspace folders? This is an endless source of complexity that we will need to justify.

I do not exactly know what the future holds for the zls.json. Maybe it does get expanded to support per-project configuration. Maybe it gets removed. But what I do know is that it's harder to remove a feature than it is to add it. I am proceeding with caution.

that encourages duplicating configuration options (.zed/settings.json, .vscode/settings.json, .sublime-project, etc)

Sharing LSP configuration between editors is a nice property of the zls.json indeed. Unfortunately editors themselves suffer from the same issue which makes it hard to set up projects to work across multiple editors in general.

Ideally there would be a way to set LSP configuration that not only works across editors but also across LSPs. Think of EditorConfig but for LSP configuration.

preferring zls.json would also resolve the "most editors" part of your comment - all editors with any form of lsp support would automatically support zls.json, regardless of whether the editor has configuration options available for zls.

As stated in the ZLS docs, there is not a single editor that I have documented which must be configured with a zls.json. (ZigBrains for JetBrains IDE's is in a bit of a weird spot) -- I am not saying to not use a zls.json in the right circumstances. What I am saying is that workspace configuration should always be the first place to look for when configuring an LSP.

It also leaves support for other build systems

The zls.json provides little for integration with other build systems. If ZLS's wants to support other build system, they will most likely need more than a zls.json.

further, as mentioned in the issue you linked (#1687), the default behavior in neovim for over 6 months now is to handle a workspace zls.json (overriding the global one if the local one is present); there's already precedent and support in the community assuming workspace zls settings are an option

I do not control how editors setup integration with ZLS. If's that how nvim-lspconfig wants to do per-project LSP configuration then that's on them. I am planning to look into how exrc and direnv can be used in Neovim.

[dotcarmen]

fair enough. thank you for writing a thorough response :)