fix(tailwindcss): only attach to existing files

[igorlfs]

The tailwind LSP behaves poorly when attaching to "virtual" buffers. I've noticed that it gets stuck with 100% CPU usage when using the "virtual buffers" from diffview (i.e., via :DiffviewOpen).

I thought about reporting this issue upstream (tailwind), but I decided to first open a PR here to get some thoughts. There's a related issue on neovim, and I understand that the current method to handle conditional attaching is using the root_dir function, but so far I haven't seen any configs using this trick, so I'm not sure if it's welcome here.

[justinmk]

should this config specify requires_workspace=true ?

the current method to handle conditional attaching is using the root_dir function, but so far I haven't seen any configs using this trick, so I'm not sure if it's welcome here.

root_dir is used in some configs here, afair.

[igorlfs]

Looks like it will be fixed on the server side, so no need for a workaround here

[justinmk]

Thanks for followup!

[thecrypticace]

o/ I'm a maintainer of the Tailwind CSS language server. I just did some research into this and the thing I thought was happening is not. It did reveal a bug that causes the exact saome issue but I think Neovim is at fault here as well. When you open file at foo://index.html Neovim will cause the server to be initialized with a workspace folder URI of file://. which resolves to the root directory (/ on *nix and \\ on Windows).

Can see more details in my comment here: https://github.com/tailwindlabs/tailwindcss-intellisense/pull/1396#issuecomment-2935953552

I think detecting a workspace folder of / is a reasonable way to work around this issue. I think I'm going to warn + ignore the workspace folder in this case. I could also basically "crash" the server by throwing an error causing it to exit. Do you have any thoughts on what I should do here?

[justinmk]

When you open file at foo://index.html Neovim will cause the server to be initialized with a workspace folder URI of file://. which resolves to the root directory (/ on *nix and \\ on Windows).

What is the lsp client expected to do in that case (arbitrary non-file scheme)? If you feel like opening an issue in core https://github.com/neovim/neovim that will be helpful, I didn't find a tracking issue for this topic.

Related: https://github.com/neovim/neovim/pull/19797

[igorlfs]

Hey Justin, I tracked down the root cause of this issue and nvim actually handles these schemes just fine. The issue arises from using vim.fs.root to define the root_dir, see this comment. Basically, with non-file buffers, the behavior of falling back to neovim's cwd returns a relative path (in this case .; which is why we see the folder URI as file://.) instead of an absolute path. If using vim.fs.find, the absolute path is returned and there's no issue with these buffers.

I can open an issue to track that, if you see fit.