aboutsummaryrefslogtreecommitdiff
path: root/runtime/ftplugin/java.vim
diff options
context:
space:
mode:
authorFreddie Haddad <6127369+freddiehaddad@users.noreply.github.com>2026-08-02 11:42:47 -0700
committerGitHub <noreply@github.com>2026-08-02 14:42:47 -0400
commit67839a72f7eba1454a1a3755a55bca5e6562e461 (patch)
tree4d6044e2caeab6674942cff458176d77c0c673e2 /runtime/ftplugin/java.vim
parent2f09090134455a75d09621821ab31f87f2c9c908 (diff)
downloadrneovim-67839a72f7eba1454a1a3755a55bca5e6562e461.tar.gz
rneovim-67839a72f7eba1454a1a3755a55bca5e6562e461.tar.bz2
rneovim-67839a72f7eba1454a1a3755a55bca5e6562e461.zip
fix(treesitter): make TSHighlighter.new() idempotent for an active buffer #41090
Problem: Calling vim.treesitter.start() a second time on a buffer that already has an active TSHighlighter creates a brand new instance instead of reusing it, whether the parser tree is unchanged (e.g. calling start() twice) or different (e.g. switching languages). Either way the old instance is silently discarded without calling :destroy() on it, so its on_bytes/on_changedtree/on_detach callbacks stay registered and its buffer-local state (spelloptions, decoration namespace) is never restored, both leaking indefinitely for an orphaned instance that nothing references anymore. Solution: Return the existing instance when TSHighlighter.active[source] is already set for the same parser tree, instead of unconditionally constructing a new one. When the tree differs instead (e.g. a language switch), destroy() the old instance first, matching stop() semantics, before constructing the new one.
Diffstat (limited to 'runtime/ftplugin/java.vim')
0 files changed, 0 insertions, 0 deletions