bug#59628: 29.0.50; treesit-beginning/end-of-defun problems in C/C++

["Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

> To reproduce, visit any C source file in the Emacs tree, turn on c-ts-mode
> or c++-ts-mode, go to the middle of some function, and type
>
>    M-: (treesit-beginning-of-defun) RET
> or
>    M-: (treesit-end-of-defun) RET
>
> This will move point to very strange places, which generally are neither the
> beginning nor the end of the function.  In very simple functions, like this
> one:
>
>   void
>   __executable_start (void)
>   {
>     emacs_abort ();
>   }
>
> the result is correct.  But once the function is even slightly more
> complicated, for example, like this:
>
>   static int
>   margin_glyphs_to_reserve (struct window *w, int total_glyphs, int margin)
>   {
>     if (margin > 0)
>       {
> 	int width = w->total_cols;
> 	double d = max (0, margin);
> 	d = min (width / 2 - 1, d);
> 	/* Since MARGIN is positive, we cannot possibly have less than
> 	   one glyph for the marginal area.  */
> 	return max (1, (int) ((double) total_glyphs / width * d));
>       }
>     return 0;
>   }
>
> the results are very far off the mark.
>
> These two functions are the only ones to move by defuns in treesit-based
> modes, right?  So they should be improved, IMO.
>

If I type

M-: (setq treesit-defun-type-regexp "function_definition") RET

treesit-beginning-of-defun and treesit-end-of-defun do the right thing.
That begs the question: Is it really necessary to have a Tree-sitter
regexp variable to match defun nodes?  If yes, should it already have a
sensible default value so things work out of the box in most major
modes?