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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#68664: 29.1.50; treesit defun commands broken with nested functions
Date: Sat, 27 Jan 2024 09:32:17 +0200

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

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





reply via email to

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