What
build_latest_parsers() spawns one mod_async.new(...) job per treesitter parser and waits on all of them via mod_async.yield(), structured to look like concurrent clone+build. But each job's body calls vim.system(...):wait() — a genuinely blocking, synchronous wait, not a coroutine yield. That freezes the whole Neovim main thread (not just that job's coroutine) until the git clone/pull and tree-sitter build for that one parser finish, before the scheduler can move on to the next job.
Where
lua/config/treesitter.lua:112-148, specifically the two :wait() calls at roughly lines 120, 122, and 134 inside the per-parser job passed to mod_async.new.
Why it matters
:TSSync latest (or whatever wires into build_latest_parsers) ends up building all ~16 parsers strictly one after another, with the UI frozen for the duration of each clone+build, despite the code structure implying they run concurrently via lib/async.lua's job scheduler. This is a distinct bug from the already-tracked synchronous vim.fn.system() glibc-version check that blocks startup — that one only fires once at startup and was already fixed; this one is UI-blocking on every manual full-parser rebuild and defeats the async design already present in this same file.
Recommended action
Replace the blocking :wait() calls with vim.system(cmd, opts, callback)'s async form, resuming the job's coroutine via mod_async from the callback (matching however other jobs in lib/async.lua bridge external async callbacks back into a job). This needs a look at lib/async.lua's job/yield contract to do correctly — not a one-line fix, hence filed as an issue rather than a mechanical PR.
What
build_latest_parsers()spawns onemod_async.new(...)job per treesitter parser and waits on all of them viamod_async.yield(), structured to look like concurrent clone+build. But each job's body callsvim.system(...):wait()— a genuinely blocking, synchronous wait, not a coroutine yield. That freezes the whole Neovim main thread (not just that job's coroutine) until the git clone/pull andtree-sitter buildfor that one parser finish, before the scheduler can move on to the next job.Where
lua/config/treesitter.lua:112-148, specifically the two:wait()calls at roughly lines 120, 122, and 134 inside the per-parser job passed tomod_async.new.Why it matters
:TSSync latest(or whatever wires intobuild_latest_parsers) ends up building all ~16 parsers strictly one after another, with the UI frozen for the duration of each clone+build, despite the code structure implying they run concurrently vialib/async.lua's job scheduler. This is a distinct bug from the already-tracked synchronousvim.fn.system()glibc-version check that blocks startup — that one only fires once at startup and was already fixed; this one is UI-blocking on every manual full-parser rebuild and defeats the async design already present in this same file.Recommended action
Replace the blocking
:wait()calls withvim.system(cmd, opts, callback)'s async form, resuming the job's coroutine viamod_asyncfrom the callback (matching however other jobs inlib/async.luabridge external async callbacks back into a job). This needs a look atlib/async.lua's job/yield contract to do correctly — not a one-line fix, hence filed as an issue rather than a mechanical PR.