You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.
Let's imagine several projects combined in one large git repository. Each of these projects has their own root folder in this repo. They are all related to each other so it makes sense to open them in 1 atom instance instead of opening several atom instances and switching between them.
AFAIK this is currently not supported by the AutoLanguageClient because the server always takes the atom root folder as projectPath that is then passed to the startServerProcess function.
There is already the determineProjectPath function on the ServerManager:
I've gone back and forth on this a few times - in the specific cases I can think of like TypeScript - it's quite difficult to determine what the root is. Do you go down the tree and start multiple language servers for each .tsconfig or go up the file system until you find a single one?
I think if we can come up with a technique/api that is flexible and allows for one or more language servers to start without breaking existing users that would be great (or perhaps it's always 1-to-1 and the TypeScript scenario is just an odd one)
Let's imagine several projects combined in one large git repository. Each of these projects has their own root folder in this repo. They are all related to each other so it makes sense to open them in 1 atom instance instead of opening several atom instances and switching between them.
AFAIK this is currently not supported by the
AutoLanguageClient
because the server always takes the atom root folder asprojectPath
that is then passed to thestartServerProcess
function.There is already the
determineProjectPath
function on theServerManager
:atom-languageclient/lib/server-manager.ts
Lines 257 to 263 in 606faa3
If this can be overwritten by the
AutoLanguageClient
in some way then I think the above mentioned problem is fixed.What do you think? I think I can prepare a PR for this.
/cc @damieng
The text was updated successfully, but these errors were encountered: