From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Code navigation for sh-mode with Tree-sitter Date: Mon, 05 Dec 2022 16:56:15 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8235"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: =?windows-1252?Q?Jo=E3o?= Paulo Labegalini de Carvalho , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 05 22:57:14 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 1p2JSa-0001rr-PZ for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Dec 2022 22:57:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p2JRn-0008Bs-8a; Mon, 05 Dec 2022 16:56:23 -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 1p2JRl-0008Bk-TM for emacs-devel@gnu.org; Mon, 05 Dec 2022 16:56:21 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p2JRj-0008Ex-VX for emacs-devel@gnu.org; Mon, 05 Dec 2022 16:56:21 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4FA984426E2; Mon, 5 Dec 2022 16:56:18 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 886264426E1; Mon, 5 Dec 2022 16:56:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1670277376; bh=g+t18Aj1ttQS1iM2vphRYxbgp8XmFGp7/IDS2PO/5bA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZKlSHDjvMF/zr02uzBUDldJ2MWgKLxSXax8NrUJekZo/yP6MsWmKvkDx7rpytiX9q zS71Nl7HTmMUDAdiycps5754sd/x8SIX0jc/4k7hmnXYVE8oV4X6wsZdtke9jM/Xun tW0e8AZrORuUor+CZtpzi9vfXSXvV7chU92xDfkWdPENKitXucK1eJKjL9hEsFS9qz 7NO6JE336Bn8ZuBy5JEoYfZZ8UE9Rl+BYPcf2Nx0/UYo50Ij9hsd6Gp55tGPfykBsA JBxlf0ZIo+ZAsCmkhr6Ia/bplPLr1fT54F+ybOJiogEm1K2jkXljOG6BWsEfRtvE9k EuZ7L0KGg6nTQ== Original-Received: from alfajor (unknown [45.44.229.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 61F141203F4; Mon, 5 Dec 2022 16:56:16 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Mon, 5 Dec 2022 21:29:32 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:300945 Archived-At: > Even the existence of the variable end-of-defun-moves-to-eol is so crass > it can't be other than broken. Jo=E3o'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). Maybe I misunderstood. I thought your claim of brokenness was relating to `beginning/end-of-defun-function` rather than to `beginning/end-of-defun`. >> 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. Exactly, and this tells you if you're after the "immediately preceding" function or inside of it. > That's entirely disregarding nested functions, and how to handle them. If you need to handle nested functions, then after the begin+end which told you you're after the previous function, you need to go back to the beginning of the previous function (i.e. where you were after the call to BODF) and call BODF again (and EODF again to check whether you started from within that outer function or not, and maybe iterate if needed). > CC Mode's C-M-e works. Jo=E3o'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? As soon as we can find an API that works *both* for the case of tree-sitter (i.e. where we have more or less direct access to a global information telling us where we are relative to the surrounding code constructs) as well as for the case where we don't have much more info than what BODF/EODF work with (i.e. a regexp to match a defun-start and a function to jump over a defun). Stefan