From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Code navigation for sh-mode with Tree-sitter Date: Mon, 5 Dec 2022 21:29:32 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32474"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?iso-8859-1?Q?Jo=E3o?= Paulo Labegalini de Carvalho , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 05 22:30:31 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p2J2k-0008Ff-Qs for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Dec 2022 22:30:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p2J28-0003Z3-7U; Mon, 05 Dec 2022 16:29:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p2J25-0003Xo-Ms for emacs-devel@gnu.org; Mon, 05 Dec 2022 16:29:49 -0500 Original-Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p2J23-0003iX-Nw for emacs-devel@gnu.org; Mon, 05 Dec 2022 16:29:49 -0500 Original-Received: (qmail 59046 invoked by uid 3782); 5 Dec 2022 22:29:33 +0100 Original-Received: from acm.muc.de (p4fe15a8e.dip0.t-ipconnect.de [79.225.90.142]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 05 Dec 2022 22:29:33 +0100 Original-Received: (qmail 8349 invoked by uid 1000); 5 Dec 2022 21:29:32 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300944 Archived-At: 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).