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

[Alan Mackenzie <acm@muc.de>]

Hello, João.

On Sat, Dec 03, 2022 at 13:23:25 -0700, João Paulo Labegalini de Carvalho wrote:
> Hi all,

> I am working on basic navigation for sh-mode. My idea is that in sh-mode
> invoking C-M-a or C-M-e moves point to the beginning/end of the
> surrounding function if the point was inside of said function or to the
> beginning/end of the next/previous top-level function otherwise.

> I got the functions to do so in the attached patch (I did not include the
> C-M-a with a negative argument yet).

> If the functions are defined and used in isolation they work as intended.
> However, because `end-of-defun' calls `beginning-of-defun-raw' (which,
> AFAIK, uses `beginning-of-defun-function') it causes the C-M-e to not work
> when the point is not inside of a function.

Yes.  beginning-of-defun and end-of-defun are broken, and have been for
a long time.  They cannot, in general, work, for the reason you've just
noted.

The problem has been raised on emacs-devel before, without the problem
getting solved.  CC Mode, for example, works around the problem by
binding c-beginning-of-defun and c-end-of-defun directly to C-M-a and
C-M-e, bypassing the offending code.

The tactic of using beginning-of-defun-raw is only valid in certain
circumstances, and is an inappropriate inefficiency in modes such as
the one you're writing, where it is just as easy to go directly to an
end of defun as a beginning of defun.

> What I think is happening is that, when `end-of-defun' calls
> `beginning-of-defun-raw' it brings point to the beginning of a top-level
> function, so the subsequent call to `end-of-defun' moves point to the start
> location, does it make it seems as the point did not move.

Yes.  I suggest you submit a bug report for this bug.

To work properly, beginning/end-of-defun need to know whether the
starting point is inside a defun or between defuns.  Your patch includes
a macro which determines this (as CC Mode includes a function which
determines this).  Possibly, a proper bug fix might include a function
supplied by the major mode for this analysis.

> I have also noticed that calling the private function I defined directly
> via M-: brings the point to a slightly different location. For example:

> <---- point before C-M-e
> A {
> } <--- point after M-: (sh-mode--treesit-end-of-defun)
> <---- pint after C-M-e

> Calling sh-mode--treesit-end-of-defun brings the point right after the
> closing curly brace and with C-M-e the point is positioned at the next line.

This is C-M-e deciding that the end of defun should be defined as
somewhere else other than the end of the function.  It seems as though
there ought to be an end-of-defun-raw function (which would be usable by
programs) and an end-of-defun which puts point where interactive use
supposedly wants it to be.

> That might be due to additional processing done inside `end-of-defun'.

Indeed.

> So, would it be ok to override `beginning-of-defun' and `end-of-defun' and
> thus have bash-ts-mode use the functions I wrote directly? If so, how could
> I do that? If not, how can I fix the "miss-behavior"?

As already mentioned, you could bind C-M-a and C-M-e directly to your
new functions in the major mode map.  Other than that, I'm convinced the
misbehaviour cannot be fixed without fixing the basic functions in
emacs-lisp/lisp.el.  Hence the suggestion of a bug report.

> I would appreciate all feedback and suggestions.



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

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).