search

seblj / roslyn.nvim

Roslyn LSP plugin for neovim
MIT License
11 stars 6 forks source link

sln target needs to be selected on every file #6

Closed marcinjahn closed 4 days ago

marcinjahn commented 5 days ago

I have a root directory with 2 sln files. When I open nvim, I have to select the solution that I'm working on. The selected solution should stay on throughout the session lifetime (unless I decide to manually change it with CSTarget). However, anytime I switch to a different file, the notification to use CSTarget pops up.

seblj commented 5 days ago

I agree. Will fix this

tilupe commented 4 days ago

As a quickfix I just check with the following function in the autocommand if the callback should just return 


local function checkForRoslyn(t)
    for i, v in pairs(t) do
        if type(v) == "table" then
            for j, w in pairs(v) do
                if j == "name" and w == "roslyn" then
                    vim.lsp.buf_attach_client(0, v["id"])
                    return true
                end
            end
        end
    end
    return false
end
marcinjahn commented 4 days ago

@seblj I see that you're kind of caching the loaded sln_dir in solutions table. When opening new file, if the solution is in the table, you're invoking the lsp_start function, which basically starts the server binary again. Is that the standard way of operating with LSPs for this kind of thing?

seblj commented 4 days ago

Aaaah you just made me realise something... So, vim.lsp.start is safe to call multiple times, but I now realise that I am running the actual dll multiple times, which is not good. I'll try to fix it right away. I think I just basically need to cache the pipe name 🤔

marcinjahn commented 4 days ago

Maybe something in the shape of @tilupe's pyramid is more appropriate then :slightly_smiling_face:

tilupe commented 4 days ago

My solution just won't work if you open two different projects, if I'm not wrong

marcinjahn commented 4 days ago

@seblj Hmm, why is the DLL executed by the plugin, and not by vim.lsp.start? It seems that vim.lsp.start handles reusing existing server, like you said.

seblj commented 4 days ago

It is because neovim is following the spec of LSP, and the spec says that the communication between a client and a server should either be through a name that the client decides, or through stdio. However, roslyn does not follow those specs and is deciding the name of the pipe themselves. So, we need to start the server ourselves, and then parse the output from the server as json, get the name of the pipe, and then I can use the methods provided by neovim to properly communicate with it...

I think I have a fix for this though, and will push in a couple of minutes

seblj commented 4 days ago

I think the latest commit should fix this issue properly, and it should also handle multiple projects, navigating between them and such (if I have thought of everything, and if the server actually supports changing projects)

marcinjahn commented 4 days ago

I played with it a bit and it looks really well. Will let know if I spot something weird :)

Btw, I think the pipe "trick" is the reason why we don't see the normal LSP info in the corner, like (some?) LSPs provide when the projects are loading.

Here's how it looks on csharp-ls:

image

https://github.com/seblj/roslyn.nvim/assets/10273406/7e1785f1-1974-4abe-a9fb-dfdfc9d8c7bd

Wouldn't replace roslyn.nvim with anything else though. Both csharp-ls and omnisharp throw lots of errors during runtime.

seblj commented 4 days ago

Btw, I think the pipe "trick" is the reason why we don't see the normal LSP info in the corner, like (some?) LSPs provide when the projects are loading.

Actually no, that is because they just don't provide an implementation for this: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#progress :(