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

[Alan Mackenzie]

Hello, Yuan.

On Tue, Dec 06, 2022 at 13:08:19 -0800, Yuan Fu wrote:


> > On Dec 6, 2022, at 1:04 PM, Yuan Fu <casouri@gmail.com> wrote:



> >> On Dec 6, 2022, at 8:48 AM, Stefan Monnier <monnier@iro.umontreal.ca> 
> >> wrote:

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


> >>> Hmm. In sh-mode `beginning-of-defun-function' is nil and in the
> >>> example below, calling `end-of-defun-function' with M-: (funcall
> >>> end-of-defun-function) brings point to fi and not the end of the
> >>> function.

> >> Many major modes do not implement those two functions in a fully
> >> reliable way, indeed.

> >> `bash-ts-mode` should be able to implement them reliably, OTOH.

> >>> In the example above, C-M-a and C-M-e do the right thing. However,
> >>> in the presence of nested functions, C-M-a and C-M-e only navigate
> >>> over top-level functions.  For example:

> >> Yes, it's a common limitation when the major mode is unable to do
> >> proper parsing of the code.

> > It seems there are not convention on whether defun movements should
> > move across top-level defun’s or both top-level and nested ones. I’ve
> > seen bug report on python-ts-mode complaining about both sides.

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

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.

> (2)
> (1)class class1():
>     prop = 0
>     def method1(self):
>         pass

>     def method2(self):
>         pass



> Yuan

-- 
Alan Mackenzie (Nuremberg, Germany).