[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions
From: |
Yuan Fu |
Subject: |
bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C |
Date: |
Thu, 6 Jul 2023 23:15:00 -0700 |
> On Jul 4, 2023, at 4:39 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Tue, 4 Jul 2023 01:41:22 -0700
>> Cc: 64442@debbugs.gnu.org
>>
>> The problem with DEFUN’s is that a DEFUN is really made of two nodes in the
>> parse tree. One for the DEFUN part, one for the body, and there isn’t a
>> parent node that encloses the two.
>>
>> The defun movement functions are not designed to handle a construct made of
>> two adjacent nodes. They can find a node, go to the beginning/end of it;
>> they can’t find a node, and go to the end of the next node.
>>
>> It sounds easy to add some hack to handle it, but really isn’t. Defun
>> movement need to support forward/backward to beg/end, that’s four movement
>> types;
>
> Why cannot we look for a top-level expression_statement node which is
> a call_expression whose function identifier is "DEFUN" and whose
> position is between the place where C-M-a was invoked and the place
> where it does find a defun?
It’s gonna be ugly, but I can take a jab at it this weekend. I’m thinking of a
wrapper function that tries to detect DEFUN before falling back to the ordinary
tree-sitter defun movement function.
>
>> on top of that you have nested defun’s.
>
> DEFUN's cannot be nested, so we don't need to consider that.
Yeah, in general C sources don’t have nested defuns, only C++ ones do. I was
trying to illustrate that it’s hard to extend existing defun movement framework
such that it handles this special case. The best solution I can think of is
what I described above.
Yuan