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: Sat, 3 Dec 2022 21:46:34 +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="8071"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?Jo=E3o?= Paulo Labegalini de Carvalho Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 03 22:47:39 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 1p1aMD-0001sV-Qu for ged-emacs-devel@m.gmane-mx.org; Sat, 03 Dec 2022 22:47:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p1aLV-0002Zs-Eg; Sat, 03 Dec 2022 16:46:53 -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 1p1aLT-0002ZV-QW for emacs-devel@gnu.org; Sat, 03 Dec 2022 16:46:51 -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 1p1aLR-0006Yg-Ri for emacs-devel@gnu.org; Sat, 03 Dec 2022 16:46:51 -0500 Original-Received: (qmail 97469 invoked by uid 3782); 3 Dec 2022 22:46:36 +0100 Original-Received: from acm.muc.de (p2e5d53d5.dip0.t-ipconnect.de [46.93.83.213]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 03 Dec 2022 22:46:35 +0100 Original-Received: (qmail 10169 invoked by uid 1000); 3 Dec 2022 21:46:34 -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:300878 Archived-At: 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).