bug-gnu-emacs
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]