Subject: Re: bug#60197: 30.0.50; beginning-of-defun broken after new treesit impl

From: Yuan Fu <[email-masked]>
Date: Tue, 20 Dec 2022 20:08:09 -0800

Theodor Thornhill <[email-masked]> writes:

> Hi, Yuan!
>
> It seems 'prog-fill-reindent-defun' is broken after the latest changes
> to treesit-beginning-of-defun.  The culprit is that we now use remap
> instead of setting the beginning-of-defun-function.  What is the
> reasoning behind that change?  Can't we just rely on the variable
> beginning-of-defun-function?

Not really, end-of-defun uses beginning/end-of-defun-function in a way
that’s incompatible with nested defuns[1]. So if we want to support
navigation nested defuns reliably we need to remap the commands instead.
In the future (ie emacs 30), we can extend the current
beginning/end-of-defun to support nested defuns, then we don’t need to
remap the commands anymore.

> I see you mentioned it is inteded to be used as a command, but surely
> both should be possible?

Could you remind me where is this function defined? I should have
updated it when I changed the defun navigation implementation. (It was
broken by my change before the defun nav change which you noticed, I
thought I’m going to fix it with the new defun nav functions, but I
forgot...)

Yuan

[1] For example, a nested defun like this:

def parent:
    (1)
    def child:
        return 0
(2) return 1
(3)

When point is at (1), end-of-defun calls beginning-of-defun-function
followed by end-of-defun-function to check if point is in a defun: if
point ends up after the starting point, then starting point is inside a
defun, and we can stop there. In this case, point ends up at
(3), because b-o-d-f goes to previous b-o-d, which is the beg of parent,
then e-o-d-f goes to (3), which is the end of that parent, and
end-of-defun stops at (3).

However, we should have gone to (2), which is the immediately following
end-of-defun.

Thanks,
Yuan