GNU bug report logs - #60197
30.0.50; beginning-of-defun broken after new treesit impl

Previous Next

Package: emacs;

Reported by: Theodor Thornhill <theo <at> thornhill.no>

Date: Mon, 19 Dec 2022 10:14:01 UTC

Severity: normal

Found in version 30.0.50

Fixed in version 29.1

Done: Yuan Fu <casouri <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Yuan Fu <casouri <at> gmail.com>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 60197 <at> debbugs.gnu.org
Subject: bug#60197: 30.0.50; beginning-of-defun broken after new treesit  impl
Date: Tue, 20 Dec 2022 20:08:09 -0800
Theodor Thornhill <theo <at> thornhill.no> 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




This bug report was last modified 2 years and 133 days ago.

Previous Next


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