Neovim completion is not working after version 0.14.11 #1323
Comments
|
Do you have a way to check the logs produced by the language server in your Neovim setup? I feel like I run into issues with this every time I try to debug neovim-related problems. If you can providing them would be very helpful. |
|
Also what Node.js version are you on? |
|
@thecrypticace LSP logs: https://gist.github.com/willian/c427579a7c731f396f15b652378a638e#file-lsp-log-L2915 |
|
Ah fantastic thank you — I've downloaded the log. I'll comb through the log and see what I can find. Also, aside, how did you get it to show these? Would love to know because It'd be super useful for me triaging issues in the future. |
|
I'm not 100% sure if its our language server (possibly) but I see this: I don't know what's causing that (I feel like it shouldn't actually be possible) but it's definitely a place for me to start |
|
Ah okay that one isn't us. It's vtsls. There's several language servers running at one time so there's lots of the same RPC IDs. But assuming I've associated things correctly we're either:
Both of these things make me thing we're not detecting class lists correctly in the file. Will need to reconstruct it and go from there. Will report back anything I discover later (tomorrow probably) |
No problem! I've added this to my Neovim config: vim.lsp.set_log_level("debug")
if vim.fn.has("nvim-0.5.1") == 1 then
require("vim.lsp.log").set_format_func(vim.inspect)
end
Yes, I saw this too. My assumption is that the LSP is returning an empty array of suggestions. It works fine when I downgrade it to 0.14.11 by running
Yes, I think your assumptions are aligned with mine. |
|
Just an update saying that the error still exists in |
|
This is happening to me as well, I get no completion in v4, but I do in v3 with the exact same config, this is my lsp log from nvim |
|
What works for me is setting the lspconfig.tailwindcss.setup({
capabilities = capabilities,
on_attach = on_attach,
root_dir = function(fname)
return vim.fs.dirname(vim.fs.find('.git', { path = fname, upward = true })[1])
end,
settings = {
tailwindCSS = {
experimental = {
configFile = "path/to/css/globals.css"
}
}
}
})currently on 0.14.4 since I'm using nix flakes. edit: my bad, this is explicitly after 0.14.11. |
This is working for me in svelte 5, the only problem now is find a way to set this dynamically |
Fixes #1302 Possibly helps #1322 Possibly helps #1323 This PR fixes a problem where files may fail to match against the appropriate project in a given workspace — and in some cases this behavior could be "fixed" by opening multiple files until all projects in a workspace had their selectors recomputed. (A selector is a file pattern/path paired with a "priority" that tells us how files match different projects in a workspace) The problem here is caused by a few things: - We fixed a bug where auto source detection in v4 silently failed in IntelliSense. After fixing this a file could get matched against one of the globs or file paths detected by Oxide. - A workspace with lots of CSS files may end up creating more than one "project" - Upon project initialization we would recompute these selectors **based on the resolved JS config** (necessary for v3 projects because we compile ESM or TS configs during intiialization and not discovery). Obviously, v4 projects do not have JS configs (even if you're using `@config` or `@plugin` it's not actually the config file we care about. It's the design system created from the CSS file that matters.) so we were then throwing away these document selectors. In a workspace with multiple detected projects (could be because of multiple CSS "roots", some v3 and some v4 files, etc…) we would check the file against the selectors of each project, pick out the most specific match, then initialize the project. The problem is that, when we re-computed these selectors during initialization they changed. This has the side effect of dropping the patterns that we picked up from Oxide for a v4 project. This would then cause any subsequent requests for a file to match a *different* project. So for example, a request to compute the document colors would cause a project to be matched then initialized. Then a hover in the same file would end up matching a completely different project. This PR addresses this by doing two things: 1. Using the same codepath for computing a projects document selectors during discovery and initalization 2. Normalize Windows drive letters in source paths picked up by Oxide. This would have the effect of some content paths not matching a project when it otherwise should on Windows. In the future it'd probably be a good idea to make documents "sticky" while they are open such that an open document picks a project and "sticks" to it. We'd still want to recompute this stickiness if the config a file is attached to changed but this is a future task as there might be side effects from doing this.
Yes, |
|
still not fix in v0.14.17 |
What version of Tailwind CSS IntelliSense are you using?
v0.14.15
What version of Tailwind CSS are you using?
v4.1.4
What package manager are you using?
npm
What operating system are you using?
macOS
Tailwind config
My Neovim config
https://github.com/willian/dotfiles/tree/main/config/nvim
Reproduction URL
https://github.com/willian/my-app/blob/main/app/frontend/pages/InertiaExample.tsx#L20
Describe your issue
I created a Rails application from scratch:
Then I installed Inertia.js like this:
[TL;DR]
I said
Yesfor all the questions, and I choose React with TypeScript and TailwindCSSThe autocompletion works when LSP version is
0.14.11:But it does not work if it is
0.14.12or above:The text was updated successfully, but these errors were encountered: