Re: Code navigation for sh-mode with Tree-sitter

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Even the existence of the variable end-of-defun-moves-to-eol is so crass
> it can't be other than broken.  João's patch contains a
> beginning-of-defun-function and and end-of-defun-function which
> intrinsically work.  Emacs's end-of-defun messes this up with it's
> ridiculous call to beginning-of-defun-raw, followed by a later call to
> (beginning-of-defun-raw -1).

Maybe I misunderstood.  I thought your claim of brokenness was relating to
`beginning/end-of-defun-function` rather than to `beginning/end-of-defun`.

>> Calling beginning-of-defun-function followed by end-of-defun-function
>> (and comparing the resulting position to the start position) should be
>> sufficient to let you know whether or not you're inside the function
>> whose definition starts most closely before point.
>
> It's not.  With starting point between two defuns, that sequence could
> leave point at any of before, at, or after starting point.

Exactly, and this tells you if you're after the "immediately preceding"
function or inside of it.

> That's entirely disregarding nested functions, and how to handle them.

If you need to handle nested functions, then after the begin+end which
told you you're after the previous function, you need to go back to the
beginning of the previous function (i.e. where you were after the call
to BODF) and call BODF again (and EODF again to check whether you
started from within that outer function or not, and maybe iterate if
needed).

> CC Mode's C-M-e works.  João's new functions look like they will work.
> Both of these analyse, as a distinct operation, the starting position to
> determine whether or not it is inside or outside a defun.  Why not fix
> the standard end-of-defun (and beginning-of-defun) in lisp.el so that it
> will likewise work?

As soon as we can find an API that works *both* for the case of
tree-sitter (i.e. where we have more or less direct access to a global
information telling us where we are relative to the surrounding code
constructs) as well as for the case where we don't have much more info
than what BODF/EODF work with (i.e. a regexp to match a defun-start and
a function to jump over a defun).


        Stefan