Subject: Re: bug#77256: Treesit language-at-point

From: Yuan Fu <[email-masked]>
Date: Wed, 16 Apr 2025 22:21:34 -0700

> On Apr 16, 2025, at 10:12 AM, Juri Linkov <[email-masked]> wrote:
> 
>>> This seems a bit convoluted to me.  What do you think about adding
>>> some hook or generic function to outline-minor-mode?
>> 
>> Is this better?
>> 
>> diff --git a/lisp/outline.el b/lisp/outline.el
>> -(defun outline--fix-buttons-after-change (beg end _len)
>> +(defvar outline-after-change nil
>> +  "List of functions to call after each text change in outline-mode.")
>> +
>> +(defun outline--fix-buttons-after-change (beg end len)
>> +  (run-hook-with-args 'outline-after-change beg end len)
>>   ;; Handle whole lines
>>   (save-excursion (goto-char beg) (setq beg (pos-bol)))
>>   (save-excursion (goto-char end) (setq end (pos-eol)))
> 
> This is pushed as well.

FTR I’m not super satisfied with how we are adding after-change hook to update ranges. But I couldn’t came up with anything in the past few days so I didn’t suggest any alternatives :-) 

Ultimately I think you are right that we want guarantee to Lisp programs that parser ranges are always up-to-date, so they don’t have to call treesit-update-ranges themselves every where. But the exact implementation to achieve that is still not super clear in my head. After thinking about this more and rewriting this reply three times, I think the best way might be to call treesit--pre-redisplay in after-change-functions. Treesit--pre-redisplay should make sure all the parser ranges are updated. The only thing I don’t like about this is that there’re many cases where a series of buffer edits are made, and we don’t want to update ranges after each single buffer edit. Post-command-hook should prevent that, but post-command-hook feels really user-facing and high-level to me.

I’d like to know what do you and Stefan think about this.

Yuan