Use a separate config file to specify root (or other plugin options)

[ArkadiuszMichalski]

Mentions:
#15 (comment)
#15 (comment)

@Ekopalypse At first I have a few basic questions:

1. Plugin uses only one server instance for each language? Regardless of the directories we operate on, only one server will be running and it will try to work on such folders (treating them as one project or separate projects depending on what commands you use)?
2. Initialization of such a server is done only once? Or maybe when we switch to a separate folder, the initialization occurs again? I'm trying to understand if we have different server configuration files in different folders, will they be processed somehow, or maybe just this one when we start a given server (or they will always be overwritten when we switching folders and that's why the server works for separate folders).
3. What exactly happens when we have 2 separate folders (or more), we start the server when the first one is active and then go to the second one? Something like that:

outside.js
dirA
    jsconfig.json
    fileA1.js
    fileA2.js

dirB
    jsconfig.json
    fileB1.js
    fileB2.js

Let's say the file fileA1.js is active, we run server, and now we go to fileB1.js. Initialization will occur 2x? Will it somehow remember the settings for both folders separately or will one overwrite the settings of the other?

I'm testing it for JS and it looks like it's able to process configurations for each folder separately (when I go to different folders they respect their configuration file). The exception is when both folders use the same file (e.g. from outside), then when I'm in such a file the hints in it only work for one folder (the one that first processed jsconfig.json).

[Ekopalypse]

Yes, only one instance of a language server is started.

The start of a server process triggers the initialization request. As long as this server is not restarted, no further initialization request is sent. As already mentioned, the client informs the server about the known root folders as part of the initialization request.

Depending on what the server supports, this means that it either responds to a single root folder or to several workspace folders. If the server supports multiple workspace folders, each time a buffer is activated, the client checks to see if the current FAW root folders have changed and informs the server of the changes if they have.

The client does NOT know how a server handles such information. Whether it treats the different root folders as different projects or as a single project depends on the server. As far as I know, there is currently no specification in the protocol that would allow a client and a server to define how to use such workspace folders.

However, there is a request that is not yet supported by the client that allows the server to ask the client how a workspace is configured or needs to be set up, at least that is my understanding.

From the perspective of NppLspClient, I would say that you can run different language servers in one session at the same time, but only have one project per server in mind. If you want to work on several projects per server in parallel, you should use different Npp instances.

[ArkadiuszMichalski]

The client does NOT know how a server handles such information. Whether it treats the different root folders as different projects or as a single project depends on the server. As far as I know, there is currently no specification in the protocol that would allow a client and a server to define how to use such workspace folders.

This means that we have to check it individually in each server, which is a bit tedious. But LSP coverage in each server is at a different level, so it's less surprising. We just need to test a lot.

If you want to work on several projects per server in parallel, you should use different Npp instances.

I eventually thought about that too, but I would rather avoid it. Fortunately, this LSP for JS works in such an interesting way that it treats such folders as different projects (I just have to use configuration files pointing to the files of a given project in each such folders).

[Ekopalypse]

I just have to use configuration files pointing to the files of a given project in each such folders

But wouldn't that mean that you have to remember to maintain this file as well?
The more I think about it, the more I don't like it.
Don't get me wrong, I can implement it, but it doesn't seem to benefit my workflow.

Think about how you work on a project - how do you do it?
I, personally, open a cmd with all the environment variables I need and start Npp from the root of such a project - done. Instead of FAW, we could also determine the current directory and then use it. But that would mean that we are now restricted to this language server.

Now suppose you were asked to review/fix a file of another project that uses the same server.
If you want to use the same npp instance, there is no guarantee that the currently running server can provide the features you assume are available due to a different language-specific project configuration file. Even if it works today, the operators of such servers might think differently in the future.
The only options I see would be to either stop the current server and restart it with the other project root or implement a client function to start another instance of that server.

However, this in turn means that workspace folders can no longer be determined. For example, if there is a file X that cannot be determined from the root directory of either project A or project B, which server should it be assigned to?

I don't like the current situation 100% either, but I don't yet see how this could really be improved.