GNU bug report logs - #64442
29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64442 in the body.
You can then email your comments to 64442 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C
Date: Mon, 03 Jul 2023 20:13:47 +0300

To reproduce:

  emacs -Q
  C-x C-f src/dispnew.c RET
  M-x c-ts-mode RET
  C-u 220 M-g g
  C-M-a

Observe that instead of going to the beginning of
dump-redisplay-history, the function to which line 220 of dispnew.c
belongs, point goes to the beginning of the previous function, which
happens to be add_frame_display_history.

Can we please fix treesit-beginning-of-defun such that it recognizes C
functions defined via DEFUN?



In GNU Emacs 29.0.92 (build 20, i686-pc-mingw32) of 2023-07-02 built on
 HOME-C4E4A596F7
Repository revision: 15ff87617772c2a2c3d8a3a1e2ed7f96e527ad9e
Repository branch: emacs-29
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: C/*

Minor modes in effect:
  bug-reference-prog-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
misearch multi-isearch c-ts-mode c-ts-common treesit cl-seq vc-git
diff-mode easy-mmode vc vc-dispatcher bug-reference byte-opt gv bytecomp
byte-compile cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs cl-loaddefs cl-lib rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty
make-network-process emacs)

Memory information:
((conses 16 81182 12528)
 (symbols 48 9662 0)
 (strings 16 28732 3398)
 (string-bytes 1 924785)
 (vectors 16 15907)
 (vector-slots 8 209599 17044)
 (floats 8 29 78)
 (intervals 40 1068 136)
 (buffers 888 11))

Message #8 received at 64442 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64442 <at> debbugs.gnu.org
Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN
 functions in C
Date: Tue, 4 Jul 2023 01:41:22 -0700

> On Jul 3, 2023, at 10:13 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> To reproduce:
> 
>  emacs -Q
>  C-x C-f src/dispnew.c RET
>  M-x c-ts-mode RET
>  C-u 220 M-g g
>  C-M-a
> 
> Observe that instead of going to the beginning of
> dump-redisplay-history, the function to which line 220 of dispnew.c
> belongs, point goes to the beginning of the previous function, which
> happens to be add_frame_display_history.
> 
> Can we please fix treesit-beginning-of-defun such that it recognizes C
> functions defined via DEFUN?

I’ve tried it when I was fixing fontification for DEFUN, but ultimately gave up. The tree-sitter defun movement functions searches for defun nodes bottom-up, and goes to the beginning or end of that node. 

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; on top of that you have nested defun’s.

Yuan

Message #11 received at 64442 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 64442 <at> debbugs.gnu.org
Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN
 functions in C
Date: Tue, 04 Jul 2023 14:39:55 +0300

> From: Yuan Fu <casouri <at> gmail.com>
> Date: Tue, 4 Jul 2023 01:41:22 -0700
> Cc: 64442 <at> 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?

> on top of that you have nested defun’s.

DEFUN's cannot be nested, so we don't need to consider that.

Thanks.

Message #14 received at 64442 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64442 <at> debbugs.gnu.org
Subject: Re: 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 <at> gnu.org> wrote:
> 
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Tue, 4 Jul 2023 01:41:22 -0700
>> Cc: 64442 <at> 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

Message #17 received at 64442 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 64442 <at> debbugs.gnu.org
Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN
 functions in C
Date: Fri, 07 Jul 2023 09:40:12 +0300

> From: Yuan Fu <casouri <at> gmail.com>
> Date: Thu, 6 Jul 2023 23:15:00 -0700
> Cc: 64442 <at> debbugs.gnu.org
> 
> > On Jul 4, 2023, at 4:39 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 
> > 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.

Thanks.  let's see how ugly it is before deciding whether it's worth it.

> > 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.

No, I meant the use of DEFUN macros in Emacs cannot be nested.

Message #20 received at 64442 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64442 <at> debbugs.gnu.org
Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN
 functions in C
Date: Tue, 11 Jul 2023 19:10:01 -0700

> On Jul 6, 2023, at 11:40 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Thu, 6 Jul 2023 23:15:00 -0700
>> Cc: 64442 <at> debbugs.gnu.org
>> 
>>> On Jul 4, 2023, at 4:39 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>> 
>>> 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.
> 
> Thanks.  let's see how ugly it is before deciding whether it's worth it.
> 
>>> 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.
> 
> No, I meant the use of DEFUN macros in Emacs cannot be nested.

Just an update. I didn’t forget about this, but it’s more harder than I thought and I’m still working on it :-(

Yuan

Message #23 received at 64442 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 64442 <at> debbugs.gnu.org
Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN
 functions in C
Date: Sun, 30 Jul 2023 10:10:35 +0300

> From: Yuan Fu <casouri <at> gmail.com>
> Date: Tue, 11 Jul 2023 19:10:01 -0700
> Cc: 64442 <at> debbugs.gnu.org
> 
> 
> 
> > On Jul 6, 2023, at 11:40 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 
> >> From: Yuan Fu <casouri <at> gmail.com>
> >> Date: Thu, 6 Jul 2023 23:15:00 -0700
> >> Cc: 64442 <at> debbugs.gnu.org
> >> 
> >>> On Jul 4, 2023, at 4:39 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >>> 
> >>> 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.
> > 
> > Thanks.  let's see how ugly it is before deciding whether it's worth it.
> > 
> >>> 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.
> > 
> > No, I meant the use of DEFUN macros in Emacs cannot be nested.
> 
> Just an update. I didn’t forget about this, but it’s more harder than I thought and I’m still working on it :-(

Any progress with this?  It would be good to have a solution in Emacs
29.2, if possible.

Thanks.

Message #26 received at 64442 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: casouri <at> gmail.com
Cc: 64442 <at> debbugs.gnu.org
Subject: Re: bug#64442: 29.0.92;
 treesit-beginning-of-defun fails in DEFUN functions in C
Date: Thu, 10 Aug 2023 12:18:52 +0300

> Cc: 64442 <at> debbugs.gnu.org
> Date: Sun, 30 Jul 2023 10:10:35 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Yuan Fu <casouri <at> gmail.com>
> > Date: Tue, 11 Jul 2023 19:10:01 -0700
> > Cc: 64442 <at> debbugs.gnu.org
> > 
> > 
> > 
> > > On Jul 6, 2023, at 11:40 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > 
> > >> From: Yuan Fu <casouri <at> gmail.com>
> > >> Date: Thu, 6 Jul 2023 23:15:00 -0700
> > >> Cc: 64442 <at> debbugs.gnu.org
> > >> 
> > >>> On Jul 4, 2023, at 4:39 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > >>> 
> > >>> 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.
> > > 
> > > Thanks.  let's see how ugly it is before deciding whether it's worth it.
> > > 
> > >>> 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.
> > > 
> > > No, I meant the use of DEFUN macros in Emacs cannot be nested.
> > 
> > Just an update. I didn’t forget about this, but it’s more harder than I thought and I’m still working on it :-(
> 
> Any progress with this?  It would be good to have a solution in Emacs
> 29.2, if possible.

Ping!

Message #29 received at 64442 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64442 <at> debbugs.gnu.org
Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN
 functions in C
Date: Thu, 10 Aug 2023 14:33:09 -0700

[Message part 1 (text/plain, inline)]

> On Aug 10, 2023, at 2:18 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> Cc: 64442 <at> debbugs.gnu.org
>> Date: Sun, 30 Jul 2023 10:10:35 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> 
>>> From: Yuan Fu <casouri <at> gmail.com>
>>> Date: Tue, 11 Jul 2023 19:10:01 -0700
>>> Cc: 64442 <at> debbugs.gnu.org
>>> 
>>> 
>>> 
>>>> On Jul 6, 2023, at 11:40 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>> 
>>>>> From: Yuan Fu <casouri <at> gmail.com>
>>>>> Date: Thu, 6 Jul 2023 23:15:00 -0700
>>>>> Cc: 64442 <at> debbugs.gnu.org
>>>>> 
>>>>>> On Jul 4, 2023, at 4:39 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>>>> 
>>>>>> 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.
>>>> 
>>>> Thanks.  let's see how ugly it is before deciding whether it's worth it.
>>>> 
>>>>>> 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.
>>>> 
>>>> No, I meant the use of DEFUN macros in Emacs cannot be nested.
>>> 
>>> Just an update. I didn’t forget about this, but it’s more harder than I thought and I’m still working on it :-(
>> 
>> Any progress with this?  It would be good to have a solution in Emacs
>> 29.2, if possible.
> 
> Ping!

I still don’t have a good solution. But I just realized that we might be able to make a little compromise: what if Emacs recognizes DEFUN, but as two separate parts (the declaration and the body), rather than one? It’s hard to make it recognize DEFUN as a single defun, but making it recognize DEFUN as two parts is easy.

Try this patch and see if you like the behavior. Personally I find it quite alright.

Yuan

[defun-nav.patch (application/octet-stream, attachment)]

Message #32 received at 64442 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 64442 <at> debbugs.gnu.org
Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN
 functions in C
Date: Sat, 12 Aug 2023 17:59:37 +0300

> From: Yuan Fu <casouri <at> gmail.com>
> Date: Thu, 10 Aug 2023 14:33:09 -0700
> Cc: 64442 <at> debbugs.gnu.org
> 
> I still don’t have a good solution. But I just realized that we might be able to make a little compromise: what if Emacs recognizes DEFUN, but as two separate parts (the declaration and the body), rather than one? It’s hard to make it recognize DEFUN as a single defun, but making it recognize DEFUN as two parts is easy.
> 
> Try this patch and see if you like the behavior. Personally I find it quite alright.

I like this much better than what we have now, thanks.  But I have a
question: can we perhaps recognize the "function" of the body as such,
and then automatically move to the previous defun, which is the right
place?  The "defun" that is the body has no name, so maybe that could
be used as a sign?  That would allow "C-x 4 a" to work inside a DEFUN,
something that still works less reliably with this patch: you must be
in the "first defun" to get it to find the name of the function.

But if improving this is hard, I'll settle for what you have now,
thanks a lot.

Message #35 received at 64442 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64442 <at> debbugs.gnu.org
Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN
 functions in C
Date: Sun, 13 Aug 2023 22:20:56 -0700

> On Aug 12, 2023, at 7:59 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Thu, 10 Aug 2023 14:33:09 -0700
>> Cc: 64442 <at> debbugs.gnu.org
>> 
>> I still don’t have a good solution. But I just realized that we might be able to make a little compromise: what if Emacs recognizes DEFUN, but as two separate parts (the declaration and the body), rather than one? It’s hard to make it recognize DEFUN as a single defun, but making it recognize DEFUN as two parts is easy.
>> 
>> Try this patch and see if you like the behavior. Personally I find it quite alright.
> 
> I like this much better than what we have now, thanks.  But I have a
> question: can we perhaps recognize the "function" of the body as such,
> and then automatically move to the previous defun, which is the right
> place?  The "defun" that is the body has no name, so maybe that could
> be used as a sign?  

We can easily tell the body from the declaration, but we can’t easily tell whether we should automatically move forward or backward. When point arrives at the point between the declaration and the body, should it move to the beginning of the next defun or the beginning of the declaration? This, plus it’s not straightforward to know whether we are in between a body and a declaration. I really don’t want to add even more cursed hacks into c-ts-mode.el :-)

> That would allow "C-x 4 a" to work inside a DEFUN,
> something that still works less reliably with this patch: you must be
> in the "first defun" to get it to find the name of the function.

C-x 4 a should’ve been fixed already. And it shouldn’t rely on this fix to work. Do you have a recipe for when it doesn’t work?

Yuan

Message #38 received at 64442 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 64442 <at> debbugs.gnu.org
Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN
 functions in C
Date: Mon, 14 Aug 2023 14:59:02 +0300

> From: Yuan Fu <casouri <at> gmail.com>
> Date: Sun, 13 Aug 2023 22:20:56 -0700
> Cc: 64442 <at> debbugs.gnu.org
> 
> > I like this much better than what we have now, thanks.  But I have a
> > question: can we perhaps recognize the "function" of the body as such,
> > and then automatically move to the previous defun, which is the right
> > place?  The "defun" that is the body has no name, so maybe that could
> > be used as a sign?  
> 
> We can easily tell the body from the declaration, but we can’t easily tell whether we should automatically move forward or backward. When point arrives at the point between the declaration and the body, should it move to the beginning of the next defun or the beginning of the declaration? This, plus it’s not straightforward to know whether we are in between a body and a declaration. I really don’t want to add even more cursed hacks into c-ts-mode.el :-)

Too bad, but okay.

> > That would allow "C-x 4 a" to work inside a DEFUN,
> > something that still works less reliably with this patch: you must be
> > in the "first defun" to get it to find the name of the function.
> 
> C-x 4 a should’ve been fixed already. And it shouldn’t rely on this fix to work. Do you have a recipe for when it doesn’t work?

Just try it with your patch.  If point is inside the body, the
function's name is not captured by "C-x 4 a".

Message #41 received at 64442 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64442 <at> debbugs.gnu.org
Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN
 functions in C
Date: Tue, 15 Aug 2023 00:30:53 -0700

[Message part 1 (text/plain, inline)]

> On Aug 14, 2023, at 4:59 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Sun, 13 Aug 2023 22:20:56 -0700
>> Cc: 64442 <at> debbugs.gnu.org
>> 
>>> I like this much better than what we have now, thanks.  But I have a
>>> question: can we perhaps recognize the "function" of the body as such,
>>> and then automatically move to the previous defun, which is the right
>>> place?  The "defun" that is the body has no name, so maybe that could
>>> be used as a sign?  
>> 
>> We can easily tell the body from the declaration, but we can’t easily tell whether we should automatically move forward or backward. When point arrives at the point between the declaration and the body, should it move to the beginning of the next defun or the beginning of the declaration? This, plus it’s not straightforward to know whether we are in between a body and a declaration. I really don’t want to add even more cursed hacks into c-ts-mode.el :-)
> 
> Too bad, but okay.
> 
>>> That would allow "C-x 4 a" to work inside a DEFUN,
>>> something that still works less reliably with this patch: you must be
>>> in the "first defun" to get it to find the name of the function.
>> 
>> C-x 4 a should’ve been fixed already. And it shouldn’t rely on this fix to work. Do you have a recipe for when it doesn’t work?
> 
> Just try it with your patch.  If point is inside the body, the
> function's name is not captured by "C-x 4 a”.

My bad, I must’ve been trying C-x 4 a in a different Emacs session, which worked. Anyway, I updated the patch and C-x 4 a should now work.

Yuan

[defun.patch (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

Message #44 received at 64442 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 64442 <at> debbugs.gnu.org
Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN
 functions in C
Date: Thu, 17 Aug 2023 11:18:22 +0300

> From: Yuan Fu <casouri <at> gmail.com>
> Date: Tue, 15 Aug 2023 00:30:53 -0700
> Cc: 64442 <at> debbugs.gnu.org
> 
> >>> That would allow "C-x 4 a" to work inside a DEFUN,
> >>> something that still works less reliably with this patch: you must be
> >>> in the "first defun" to get it to find the name of the function.
> >> 
> >> C-x 4 a should’ve been fixed already. And it shouldn’t rely on this fix to work. Do you have a recipe for when it doesn’t work?
> > 
> > Just try it with your patch.  If point is inside the body, the
> > function's name is not captured by "C-x 4 a”.
> 
> My bad, I must’ve been trying C-x 4 a in a different Emacs session, which worked. Anyway, I updated the patch and C-x 4 a should now work.

Thanks, LGTM.  Please install on the emacs-29 branch, and close the
bug when you do.

Message #49 received at 64442-done <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64442-done <at> debbugs.gnu.org
Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN 
 functions in C
Date: Sat, 19 Aug 2023 15:00:52 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Tue, 15 Aug 2023 00:30:53 -0700
>> Cc: 64442 <at> debbugs.gnu.org
>> 
>> >>> That would allow "C-x 4 a" to work inside a DEFUN,
>> >>> something that still works less reliably with this patch: you
>> >>> must be
>> >>> in the "first defun" to get it to find the name of the function.
>> >> 
>> >> C-x 4 a should’ve been fixed already. And it shouldn’t rely on
>> >> this fix to work. Do you have a recipe for when it doesn’t work?
>> > 
>> > Just try it with your patch.  If point is inside the body, the
>> > function's name is not captured by "C-x 4 a”.
>> 
>> My bad, I must’ve been trying C-x 4 a in a different Emacs session,
>> which worked. Anyway, I updated the patch and C-x 4 a should now
>> work.
>
> Thanks, LGTM.  Please install on the emacs-29 branch, and close the
> bug when you do.

Pushed, thanks.

Yuan

Previous Next

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