treesitter parser [swift] having issue when lazy-loading ts-related plugins
Saafo opened this issue · comments
Version confirmation
- Confirm
Following prerequisites
- Confirm
Not a user config issue
- Confirm
Neovim version
0.9.5
Operating system/version
14.2.1
Terminal name/version
Warp
$TERM environment variable
No response
Branch info
main (Default/Latest)
Fetch Preferences
SSH (use_ssh = true)
How to reproduce the issue
- open a swift file(empty is ok, and add
import Foundation
and so on)
Expected behavior
No error occurred.
Actual behavior
Some error occurred.
Additional information
I'm not sure whether it's reproducible on other devices.
seems like an upstream issue.
I'm not sure which upstream it relates to 😭 so I post it here
I'm not sure which upstream it relates to 😭 so I post it here
It seems like this issue is indeed on our end. I also work with Swift daily and can reliably reproduce this problem:
Just a quick confirmation: have u followed the instructions outlined in one of our pinned issues to obliterate any potential treesitter-compiled binary issues? If that doesn't work, u could try waiting for 1-2 secs after entering the TUI but before starting ur editing.1
Footnotes
-
At first glance it appears that the problem is related to how Treesitter operates. We load Treesitter on the
BufReadPre
event with its configuration (function) wrapped inside a scheduled event. This might be accidentally blocked by other ongoing operations, mainly because the parser itself is slow or the file is large. Consequently, one may observe that the file isn't being parsed, and Treesitter highlights aren't being applied (hence the error). I'll work on a fix later once I've identified the root cause. For now, the workaround I can suggest is precisely the one I mentioned earlier. ↩
@Jint-lzxy Thanks for the hint! I tried the solution (TSUpdate && TSInstall! swift) and restart nvim, the issue is gone. Does this work for you?
Another issue is that I've met the tree-sitter or other plugins issue once before, and I notice that the error continues generate no matter how I press enter or esc. This prevents me from using nvim AS A BASIC TEXT EDITOR. I think the error of tree sitter shouldn't prevent the most basic text edit feature.
I tried the solution (TSUpdate && TSInstall! swift) and restart nvim, the issue is gone. Does this work for you?
Yeah I find it super handy for like 99% of parser-related issues lol
Another issue is that I've met the tree-sitter or other plugins issue once before, and I notice that the error continues generate no matter how I press enter or esc. This prevents me from using nvim AS A BASIC TEXT EDITOR. I think the error of tree sitter shouldn't prevent the most basic text edit feature.
Yep that's exactly what I was saying earlier, and your points totally make sense. I switched the loading event to BufReadPost
for Treesitter recently, and haven't had any problems since. I'll give it a thorough test later, but I'm pretty sure this should be the right way to go lmao
@Jint-lzxy I switch to 0.10 branch and the prevents me from using nvim AS A BASIC TEXT EDITOR
issue still occurred until I synced plugins in Lazy(maybe upgraded nvim-treesitter?)
ys, u need to do Lazy sync
form time to time.
But I see that the issue that prevents me from using nvim as a basic text editor still exist. Once there's some issues with nvim-treesitter, I cannot use nvim editor completely. Can we convert nvim-treesitter's error to notification instead of a stack output which interrupt my interaction?
But I see that the issue that prevents me from using nvim as a basic text editor still exist. Once there's some issues with nvim-treesitter, I cannot use nvim editor completely. Can we convert nvim-treesitter's error to notification instead of a stack output which interrupt my interaction?
@Saafo Did u mean the exact same scenario as #1230 (comment)? In 0.10, I'm pretty sure this can be resolved by following #393 (comment), as the issue I described in #1230 (comment) was actually caused by some lazy-loaded component(s) bringing about the trouble. However, now that the core functionality is being integrated into Neovim (vim.treesitter
), this should no longer be an issue lol
@Saafo Did u mean the exact same scenario as #1230 (comment)? In 0.10, I'm pretty sure this can be resolved by following #393 (comment), as the issue I described in #1230 (comment) was actually caused by some lazy-loaded component(s) bringing about the trouble. However, now that the core functionality is being integrated into Neovim (
vim.treesitter
), this should no longer be an issue lol
I'm not sure which case I've met. Let's just let it go😆, I'll report another issue if I encounter in the future.