GNU bug report logs - #78402
treesit after-change-functions

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Tue, 13 May 2025 06:34:02 UTC

Severity: normal

To reply to this bug, email your comments to 78402 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to monnier <at> iro.umontreal.ca, casouri <at> gmail.com, bug-gnu-emacs <at> gnu.org:
bug#78402; Package emacs. (Tue, 13 May 2025 06:34:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Juri Linkov <juri <at> linkov.net>:
New bug report received and forwarded. Copy sent to monnier <at> iro.umontreal.ca, casouri <at> gmail.com, bug-gnu-emacs <at> gnu.org. (Tue, 13 May 2025 06:34:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: treesit after-change-functions
Date: Tue, 13 May 2025 09:27:45 +0300
This new request is the continuation from bug#77256 and
https://lists.gnu.org/archive/html/emacs-devel/2025-05/msg00300.html
about updating treesit ranges for after-change-functions,
particularly for outline--fix-buttons-after-change that uses ranges.

Hopefully Yuan could verify how implementable is this:

> BTW the fix should be fairly simple, AFAICT: the `treesit.c` code is
> told about the buffer change before `after-change-functions` runs, so it
> can record "ranges need to be updated" somewhere, and then lazily update
> the ranges next time some code uses treesit functions that depend on the
> ranges (e.g. outline's after-change function).  If the fully automatic
> lazy update is too eager, we can delay it to an explicit call to
> `treesit-ensure-ranges-are-uptodate` which outline's after-change
> function would have to call manually (same as all other current calls
> to `treesit-update-ranges`)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78402; Package emacs. (Thu, 15 May 2025 07:12:02 GMT) Full text and rfc822 format available.

Message #8 received at 78402 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 78402 <at> debbugs.gnu.org
Subject: Re: bug#78402: treesit after-change-functions
Date: Thu, 15 May 2025 00:10:57 -0700

> On May 12, 2025, at 11:27 PM, Juri Linkov <juri <at> linkov.net> wrote:
> 
> This new request is the continuation from bug#77256 and
> https://lists.gnu.org/archive/html/emacs-devel/2025-05/msg00300.html
> about updating treesit ranges for after-change-functions,
> particularly for outline--fix-buttons-after-change that uses ranges.
> 
> Hopefully Yuan could verify how implementable is this:
> 
>> BTW the fix should be fairly simple, AFAICT: the `treesit.c` code is
>> told about the buffer change before `after-change-functions` runs, so it
>> can record "ranges need to be updated" somewhere, and then lazily update
>> the ranges next time some code uses treesit functions that depend on the
>> ranges (e.g. outline's after-change function).  If the fully automatic
>> lazy update is too eager, we can delay it to an explicit call to
>> `treesit-ensure-ranges-are-uptodate` which outline's after-change
>> function would have to call manually (same as all other current calls
>> to `treesit-update-ranges`)

First of all, the affected range could be larger than the changed range (think inserting “/*” into a C buffer, everything behind the /* is affected). And you don’t really need to remember the changed range, we already does that in the form of updating the existing tree-sitter parse-tree with buffer edit information. When we finally re-parse the buffer, the parser knows the affected range. And we already rely on that information to selectively update ranges. Specifically, we get the affected regions of the primary parser (which should be the superset of all the affected ranges of all the embedded parsers), and update embedded parser ranges in those regions.

It seems that we only need to invoke treesit--pre-redisplay whenever the root node is accessed (you have to get the root node to accessing any node in the parse tree). treesit--pre-redisplay, if haven’t called since last buffer-chars-modified-tick, will force a re-parse on the primary parser, get the affected region, and update ranges for embedded parsers on the region.

Let me ponder on this a bit more to make sure it’s actually a good idea.

Btw, what’s the issue we’re trying to fix here? If some lisp want to have up-to-date ranges, it can just call treesit--pre-redisplay or treesit-update-ranges. Why do we get the node-outdated error?

Yuan



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78402; Package emacs. (Thu, 15 May 2025 17:09:01 GMT) Full text and rfc822 format available.

Message #11 received at 78402 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Yuan Fu <casouri <at> gmail.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 78402 <at> debbugs.gnu.org
Subject: Re: bug#78402: treesit after-change-functions
Date: Thu, 15 May 2025 20:06:14 +0300
> Btw, what’s the issue we’re trying to fix here? If some lisp want to
> have up-to-date ranges, it can just call treesit--pre-redisplay or
> treesit-update-ranges. Why do we get the node-outdated error?

One example where this is needed is updating the outline buttons
based on the changed text in a ts-mode buffer.

Either after-change-functions or jit-lock-function calls
outline--fix-up-all-buttons that uses treesit-outline-search
that requires the updated ranges.

I see that treesit-indent and treesit-indent-region
explicitly calls treesit-update-ranges at the beginning.
Is it how treesit command are intended to update ranges
for themselves?  It would be inefficient to call
treesit-update-ranges in treesit-outline-search.




This bug report was last modified today.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.