LSP does not work with multiple workspaces

[chrisgrieser]

So with most other LSPs, when I open a file from a different workspace, they attach correctly to the second workspace, using a different root-directory. This means (among other things that are less relevant for the typos-lsp) that when I am in a file of workspace A, the config file at the root of workspace A is active, and when I am in a file of workspace, the config file of workspace B is active.

However, when using the typos-lsp and opening a file from workspace B, typos-lsp still uses the root directory from workspace A. This results in the LSP using the typos.toml from workspace A, even though I am in workspace B, unsurprisingly resulting in various issues like wrong ignored words not being applied etc.

[tekumara]

Thanks for raising this! Could you share the file paths for both workspaces in question here? I'm wondering if they are nested 🤔

And what's an example of another open-source LSP that has the behaviour you'd like? This will be useful for me to compare behaviour with and potentially reverse engineer.

[chrisgrieser]

Hmmm, now that you mention it, it looks like most of the LSPs I use are closed source :/

But indeed, it was an issue with nested workspaces. Restructuring the repo to not have a typos.toml in one directory and its ancestors at the same time seems to solve the issue 🤔

[tekumara]

Glad you've found a solution. I'm still not sure how this is occurring. The default behaviour of typos is it will search the target path first and then its parent directories for a typos config file. The first config file found is used.

typos-lsp inherits this behaviour for consistency. In typos-lsp the target path is the workspace folder. Which means its parents will also be searched for a typos config file if there are none in the workspace folder.

So, if workspace folder B has a typos config file, and was a subdirectory of workspace folder A, then workspace B should still use its typos config file.

If you are noticing different behaviour from typos-lsp vs typos then that's something I can try replicating and looking into.

NB: in the case of a multi-root workspace containing both folder A and folder B the behaviour is different again. I'm assuming you don't have a multi-root workspace here.

[chrisgrieser]

might have something to do with the way the nvim LSP client searches root directories 🤔 https://github.com/neovim/nvim-lspconfig/blob/master/lua/lspconfig/server_configurations/typos_lsp.lua#L7

[tekumara]

Yeh possibly, if root_pattern searches parent directories too, and there's a typos.toml there, maybe? It's a bit hard for me to tell without being a nvim LSP user and knowing what your nested directory structure is.

[chrisgrieser]

yeah, the issue did not occur anymore after avoiding the nested typos.tomls. I think further investigation is probably not worth it – will re-open if I find a case where the issue occurs again

[chrisgrieser]

Okay, I now have found a case where nested workspaces can indeed create a problem.

So I have a mono-repo, where some subfolders have a typos.toml, and others do not:

- project
    - .git
    - subproject A
        - typos.toml
        - foobar-A.py
        - ...
    - subproject B
        - foobar-B.js
        - ...

When opening foobar-B.js in subproject B, typos-lsp cannot find a typos.toml and then uses project as root, since the .git is also used by nvim-lspconfig as indicators of a root directory.

If I then switch from foobar-B.js to foobar-A.py, the typos.toml file in project A is not picked up. A look at the LSP information in nvim (:LspInfo) shows that the typos-lsp still uses project as root, and not subproject A. So it seems that not the upward but rather the missing downward search is what causes an issue here.

[chrisgrieser]

Not 100% sure whether fix all issues, but as far as I can tell, removing .git as root pattern solves this particular problem. I've made a respective PR at nvim-lsp-config: https://github.com/neovim/nvim-lspconfig/pull/2935

[tekumara]

Thanks for the follow-up. So IIUC it sounds like an nvim-lsp-config thing.

[chrisgrieser]

Not 100% sure whether this is solely a nvim-lspconfig issue, or an issue resulting from the nvim-lspconfig and this LSP interacting in an unlucky way. At least for nvim, the issue appears to be fixed since my PR got merged, yes.