I completed my patch to add basic navigation to bash-ts-mode.

It works consistently when the new navigation
functions (`sh-mode--treesit-beginning-of-defun' and
`sh-mode--treesit-end-of-defun') are bound directly to C-M-a/e. However, if
those functions are bound to `beginning-of-defun-function' and
`end-of-defun-function', C-M-e does not work with negative arguments inside
of functions.

In the example below C-u - 1 C-M-e goes to the beginning of foo and not to
end of bar when point is inside foo, and anywhere after bar:

function foo {
    function bar {
        echo "Hello from bar"
    }
    if [[ $1 > 0 ]]; then
        return 42
    else
        return 24
    fi
    echo bar
}

Any comments and feedback on the patch are welcomed.

On Tue, Dec 6, 2022 at 2:46 PM João Paulo Labegalini de Carvalho <
jaopaulolc@gmail.com> wrote:

> > > Should we make it configurable, then? A variable that makes
>> > > tree-sitter defun navigation switch between two modes: top-level only
>> > > and not top-level only.
>>
>> In CC Mode, it has been configurable via the user option c-defun-tactic
>> for somewhere between ten and fifteen years.  When c-defun-tactic is t,
>> C-M-a/e go to the start/end of the top level defuns.  When it is the
>> symbol go-outward, C-M-a/e move to the next start/end of defun, if any,
>> at the current level of class/namespace nesting, and move outwards to
>> the next level of class/namespace nesting when a class/namespace boundary
>> is reached.
>>
>
> The 'go-outward behavior is the one I have implemented.
>
> I don't remember any complaints about this mechanism.
>>
>> > And for functions nested in a class: if you type C-M-e at the beginning
>> > of a class, should it go to the end of the first function in that
>> > class, or should it go to the end of the class? Right now because of
>> > how end-of-defun works, it will jump to the end of the class if point
>> > is at the beginning of the class (1), and jump to the first function if
>> > point is before the beginning of the class (2).
>>
>> This doesn't seem sensible.
>>
>
> I tend to agree. I would expect it to go to the nearest node (either class
> or function) and not bypass a class node in favor of function nodes.
>
> --
> João Paulo L. de Carvalho
> Ph.D Computer Science |  IC-UNICAMP | Campinas , SP - Brazil
> Postdoctoral Research Fellow | University of Alberta | Edmonton, AB -
> Canada
> joao.carvalho@ic.unicamp.br
> joao.carvalho@ualberta.ca
>


-- 
João Paulo L. de Carvalho
Ph.D Computer Science |  IC-UNICAMP | Campinas , SP - Brazil
Postdoctoral Research Fellow | University of Alberta | Edmonton, AB - Canada
joao.carvalho@ic.unicamp.br
joao.carvalho@ualberta.ca