Configure include or exclude patterns for each server

[skellyb]

I'd like to enable different servers in specific project directories. This becomes an issue when working with the same language with multiple runtimes.

In this example, LSP-typescript would apply to all TS/JS files in the project, except those in the server directory. Deno LSP would handle that directory. It might look something like:

{
  "folders":
  [
    {
      "path": ".",
    },
  ],
  "settings":
  {
    "LSP":
    {
      "Deno":
      {
        "enabled": true,
        "includes": ["server"],
      },
      "LSP-typescript":
      {
        "enabled": true,
        "excludes": ["server"],
      },
    },
  },
}

In the meantime I'm trying to use the Deno LSP for everything, changing configuration in each directory. I don't think that is going to work out.

If there's anything I can do to help, please let me know.

[jwortmann]

I would probably call them "include_patterns" and "exclude_patterns", and they should accept a list of either glob patterns, or Sublime patterns (probably the latter).

Two more use cases:

1. I have seen a draft PR for the Julia server to handle files named Project.toml (and JuliaProject.toml), which are the configuration files for Julia packages. It would for example show things like code lenses to update dependencies specified in that file. Here the server should only attach to files with that specific name, not for all TOML files, so the "selector" config with the syntax scope is not sufficient in this case. The PR seems to be abandoned, so this is not very urgent, but I could imagine a similar feature being adopted by other servers in the future, e.g. for Cargo.toml in Rust. And the Gopls server seems to already have it for go.mod configuration files, though those files have a unique file extension with corresponding syntax scope. I've thought about an alternative approach where an LSP-* helper package would simply provide a syntax alias for the particular file names (similar to what AFileIcon does), but I think that would be very fragile because the TOML syntax is not one of the default syntaxes shipped with Sublime Text.

2. There seems to be a (planned?) convention for .copilotignore files, which can list ignore patterns, similar to .gitignore, for files that should be ignored by GitHub Copilot. For this we probably need a new plugin API method like AbstractPlugin.additional_exclude_patterns, so that a helper package like LSP-copilot can read the .copilotignore file and provide those patterns to LSP. Or alternatively a method AbstractPlugin.should_attach(self, uri: DocumentUri) -> bool (defaults to True) which would be called whenever a new file (with the matching selector) gets opened and determines whether the server should be attached to that file. But I think this would not work for the very first file, when the instance of AbstractPlugin is not yet created.