Support registering file watchers statically on initialize.

[kdvolder]

I'm trying to understand the intention of the spec around 'didChangeWatchedFiles'. I think I understand the behavior for when 'dynamicRegistration' flag is set to 'true' in ClientCapabilities. In a nutshel, in that case, the server can register dynamically with specific glob patterns the server is interested in.

However, if 'dynamicRegistration' is set to false. What does that mean then?

Following along with other 'static' regustrations, I was expecting there would be a something in ServerCapabilities (returned by server initialization) where a server could somehow declare the patterns of files its interested in. But there doesn't seem to be anything like that.

So that brings me to my question, how does a server, in the static case, declare which file changes the server is interested in?

[dbaeumer]

Good point. You can't right now. In a first implementation I made that a configuration in the client library.

But it would be quite straight forward to add it. Code wise here: https://github.com/Microsoft/vscode-languageserver-node/blob/dbaeumer/declarationSupport/client/src/client.ts#L1148

The DidChangeWatchedFilesRegistrationOptions can be reused for the server caoabilities.

Interested in providing a PR?

[kdvolder]

I'm not opposed to adding something to the protocol to allow static registration for 'DidChangeWatchedFiles'. But that wasn't actually what I was really asking here. I did sort of expect there to be a static version as a 'companion' to the dynamic version. Especially when there's a boolean flag to indicate whether the dynamic version is supported.

However, for the time being I would just settle for adding a few words to the spec to say explicitly what a server can expect right now from a client that sets the flag to false.

It seems like the answer to this question (what can a server expect from a client that sets dynamic registration to false?) may actually be 'nothing' (at the moment).

While that's not a very great state of affairs, having this be spelled out clearly in the spec would have saved me a bit of time trying to figure out how/if I could use a 'static registration option' that is simply not there (yet).

[dbaeumer]

I clarified this as suggested. Still keeping this open to add static file watching configuration.

[radeksimko]

It makes sense for "generic" (not language-specific) clients to need it in order to decide which server to talk to when opening files/folders - I assume this is also essential for multiple servers with overlapping functionality co-existing.

IMO though the server typically holds the most knowledge about the language and should know better what extensions are actually relevant also know this may differ between language versions.

So I'm thinking if the server is allowed to "announce" its own watchers, the client should always honour these and only have the option to reduce the list, but not expand.

i.e. it wouldn't make much sense for a client to send *.py changes to a server which only supports *.go

This assumes clients implement the filtering correctly and run paths first through client's and then server's glob patterns, so that e.g. if client registers for *.*, server supports *.go and main.go changes, the notification still goes through.