all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "João Paulo Labegalini de Carvalho" <jaopaulolc@gmail.com>,
	emacs-devel@gnu.org
Subject: Re: Code navigation for sh-mode with Tree-sitter
Date: Mon, 5 Dec 2022 21:29:32 +0000	[thread overview]
Message-ID: <Y45ivJU3gSxAgLLR@ACM> (raw)
In-Reply-To: <jwvv8mp1ung.fsf-monnier+emacs@gnu.org>

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



  reply	other threads:[~2022-12-05 21:29 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-03 20:23 Code navigation for sh-mode with Tree-sitter João Paulo Labegalini de Carvalho
2022-12-03 21:46 ` Alan Mackenzie
2022-12-05 15:24   ` João Paulo Labegalini de Carvalho
2022-12-05 20:12     ` Stefan Monnier
2022-12-05 21:29       ` Alan Mackenzie [this message]
2022-12-05 21:56         ` Stefan Monnier
2022-12-06 15:51       ` João Paulo Labegalini de Carvalho
2022-12-06 16:48         ` Stefan Monnier
2022-12-06 21:04           ` Yuan Fu
2022-12-06 21:08             ` Yuan Fu
2022-12-06 21:40               ` Alan Mackenzie
2022-12-06 21:46                 ` João Paulo Labegalini de Carvalho
2022-12-06 21:55                   ` João Paulo Labegalini de Carvalho
2022-12-06 22:35                     ` Stefan Monnier
2022-12-06 22:41                       ` João Paulo Labegalini de Carvalho
2022-12-06 22:57                       ` Stefan Monnier
2022-12-06 23:43                         ` João Paulo Labegalini de Carvalho
2022-12-06 23:50                           ` Stefan Monnier
2022-12-07  1:12                             ` João Paulo Labegalini de Carvalho
2022-12-07 17:20                               ` João Paulo Labegalini de Carvalho
2022-12-10  4:58                                 ` Yuan Fu
2022-12-13  4:55                                 ` Yuan Fu
2022-12-13 16:00                                   ` João Paulo Labegalini de Carvalho
2022-12-13  5:20                                 ` New defun navigation for tree-sitter (Was: Code navigation for sh-mode with Tree-sitter) Yuan Fu
2022-12-13 16:11                                   ` João Paulo Labegalini de Carvalho
2022-12-13 16:38                                     ` Eli Zaretskii
2022-12-13 18:03                                       ` João Paulo Labegalini de Carvalho
2022-12-13 18:07                                     ` Yuan Fu
2022-12-13 18:48                                       ` João Paulo Labegalini de Carvalho
2022-12-13 18:56                                         ` Yuan Fu
2022-12-13 19:46                                           ` João Paulo Labegalini de Carvalho
2022-12-16  1:49                                             ` Yuan Fu
2022-12-16 16:24                                               ` João Paulo Labegalini de Carvalho
2022-12-17 23:32                                                 ` Yuan Fu
2022-12-07  0:41                 ` Code navigation for sh-mode with Tree-sitter Yuan Fu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y45ivJU3gSxAgLLR@ACM \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=jaopaulolc@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.