bug#68664: 29.1.50; treesit defun commands broken with nested functions

[Yuan Fu]

> On Jan 26, 2024, at 11:32 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Cc: 68664@debbugs.gnu.org, Daniel Martín <mardani29@yahoo.es>
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Fri, 26 Jan 2024 20:26:38 -0800
>> 
>>> To add further support to my belief that the current implementation is
>>> not the expected behavior, consider how the current implementation
>>> behaves when used with mark-defun.  When the point is on the call to
>>> innerFunction and I execute "M-x mark-defun RET", the nested function
>>> following the point (i.e., innerFunction2) is selected rather than the
>>> function containing point.  For comparison, the non-tree-sitter
>>> python-mode behaves correctly and selects the function containing
>>> point, not the next nested function.
>> 
>> Yeah, I mean, I can definitely see the validity of the behavior you’re 
>> describing. But I think the current behavior is equally valid. Right now you 
>> can easily go to the previous/next sibling in the same level, _and_ go to 
>> the beginning/end of the parent. You just need to press a few more times. 
>> OTOH if you go straight to the parent, there’s no way to go to siblings.
> 
> Maybe we could support both behaviors via specially-valued prefix
> arguments?  Like "C-u" means something, "C-u C-u" means something
> else, etc.?

Beginning/end-of-defun already take a numerical interactive arg, unless I 
missed something we can’t add another. If we want to change behavior 
interactively we would need something more elaborate, maybe transient maps.

> 
>> As for mark-defun, I think it’s similarly equally valid to either mark the 
>> next sibling or the parent. Right now mark-defun doesn’t really have a 
>> notion of nested defun, we should upgrade it to support nested defun like we 
>> did beginning/end-of-defun, either by a toggle like mark-defun-tactic or let 
>> user control which defun to mark interactively.
> 
> Same here.
> 
> WDYT?

Same for mark-defun, it also has an interactive arg already.

I feel like I missed something, surely you know they already have interactive 
args :-)

Yuan