GNU bug report logs -
#68664
29.1.50; treesit defun commands broken with nested functions
Previous Next
Full log
Message #23 received at 68664 <at> debbugs.gnu.org (full text, mbox):
> On Jan 24, 2024, at 9:25 AM, Troy Brown <brownts <at> troybrown.dev> wrote:
>
> On Wed, Jan 24, 2024 at 9:13 AM Troy Brown <brownts <at> troybrown.dev> wrote:
>>
>> On Wed, Jan 24, 2024 at 1:29 AM Yuan Fu <casouri <at> gmail.com> wrote:
>>>
>>> The behavior is expected. But I can see that it doesn’t match your expectations. The logic behind the current behavior is to first move between siblings in the same level; if there’s no sibling to move across anymore, move to the beginning/end of the immediate parent, and so on.
>>>
>>> To get the behavior you want, we would need to add a fourth defun navigation tactic, in addition to the existing three: nested, top-level, and restricted.
>>>
>>> If you are interested and able, maybe you can look into adding it to treesit--navigate-thing or treesit-beginning/end-of-defun?
>>>
>>> Yuan
>>
>> I find it quite odd that this is the expected behavior. Per the Emacs
>> manual (section "Moving by Defuns"), I expected the point to be moved
>> to the "innermost defun around point", since treesit-defun-tactic is
>> set to "nested", as that is precisely what is documented there. I
>> interpret "innermost defun around point" to mean the innermost defun
>> that encompasses point. Additionally, the documentation strings for
>> treesit-beginning-of-defun and treesit-end-of-defun indicate that they
>> are a tree-sitter equivalent of the beginning-of-defun and
>> end-of-defun commands respectively. If so, and since they are mapped
>> to the same key bindings in the tree-sitter modes, shouldn't the
>> expectation be that they behave the same way as the non-tree-sitter
>> commands? If not, people transitioning between the non-tree-sitter
>> mode and the tree-sitter mode are in for a surprise when the commands
>> behave differently.
>>
>> With the current behavior there is no way to move the point directly
>> to the beginning of the function without moving through all of the
>> nested functions first, which could be significant. When you say the
>> behavior is to "move between siblings in the same level", should the
>> level refer to where point is, or to the level corresponding to the
>> function encompassing the point? I think it probably makes sense to
>> move between siblings if you are at a function boundary (there is a
>> function immediately before or after the point), but if you are
>> already deep in a function, I think it makes sense to first move to
>> that function's begin/end before attempting to move between siblings.
>> I believe this behavior would be consistent with the non-tree-sitter
>> modes and expectations based on the description in the manual.
>
> 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.
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.
Yuan
This bug report was last modified 1 year and 141 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.