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

[Alan Mackenzie]

Hello, Stefan.

On Mon, Dec 05, 2022 at 15:12:22 -0500, Stefan Monnier wrote:
> >> 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.
> > Thanks for confirming this, Alan. For a moment I thought that I was making
> > one of those elisp newbie mistakes.

> Well, "broken" is an opinion, not a fact.  AFAIK they can work.  Maybe
> not as efficiently as some other API, but that's a different question.

In which case, why not amend emacs-lisp-mode so that it works for .el
buffers?  It currently doesn't do so in the general case.  I don't
dispute it does so for commonly encountered special cases.

For example, insert the defuns foo and bar into lisp/emacs-lisp/lisp.el
just before end-of-defun-moves-to-eol, the pertinent bit of the result
looking like:

1. (defun foo ())    (defun bar ())

3. (defvar end-of-defun-moves-to-eol t
4.   "Whether `end-of-defun' moves to eol before doing anything else.
5.   Set this to nil if this movement adversely affects the buffer's
6.   major mode's decisions about context.")

Put point at the beginning of L1.  C-M-e goes not to the end of foo, but
the beginning of bar.  A small point, but, I believe, an important one
to the OP João.

Now with point at this position, the start of bar, type C-M-e again.
Point jumps to BOL 7, having moved forward over both bar and
end-of-defun-moves-to-eol.

Are you maintaining that it is just my opinion that this behaviour is
broken?

We had a long discussion about this sort of thing in 2009.  It was
broken then, and it's still broken now.

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

> > I think for now I will use the same workaround.

> I'd urge you to try and find a way to make it work without such
> a workaround.

I'm convinced this is not possible.  Filipp Gunbin didn't manage it when
he re-reported the problem some months ago.  I think it's likely other
people may have reported the problem in the years since 2009.

> >> Yes.  I suggest you submit a bug report for this bug.
> > I will put some time into this and see if I can come up with a patch
> > before flagging it as a bug.

> Once you get it to work without the above workaround, you'll be able to
> write a much better bug report.

> >> To work properly, beginning/end-of-defun need to know whether the
> >> starting point is inside a defun or between defuns.

> 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.  That's
entirely disregarding nested functions, and how to handle them.

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?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).