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 15:12:22 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39469"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Alan Mackenzie , emacs-devel@gnu.org To: =?windows-1252?Q?Jo=E3o?= Paulo Labegalini de Carvalho Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 05 21:13:16 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 1p2Hpz-000A3s-Au for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Dec 2022 21:13:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p2HpS-0001VR-BT; Mon, 05 Dec 2022 15:12:42 -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 1p2HpQ-0001VG-NG for emacs-devel@gnu.org; Mon, 05 Dec 2022 15:12:40 -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 1p2HpD-0008LL-IE for emacs-devel@gnu.org; Mon, 05 Dec 2022 15:12:39 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 544D34426B7; Mon, 5 Dec 2022 15:12:25 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 753184426B1; Mon, 5 Dec 2022 15:12:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1670271143; bh=zuoowLaMqSDdFYR4lT1tqKwMcbi8+KpYeAtJLyxYar0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ksyz4CuRfg4VS38BvTpYyCl4JZJKO56MqalsGoiU15FmsBpWv7rrdGyXTtAGWiyo8 uOzUrHmpbOi+1znK5vLHAWrOPNlKRybrfIH9XEyPC3dKOEYNadoKqVnw3LEAMq5hDc ppeuHpCyXCgDJcmK5S0eZ7W9HF0ceDg0iLnjn3nx0Fao24kKBJqa0wMJ6KMpbQKnGv suKqtww2JSe+XIWiL6u1qgrYeIetq8v1798T8k5jFxDoiAgDXDIP85fuBDdg3nc9CC 442DPKp8GqPi487WnzoIl+Tf89XC/LYqMhjviYvaF3PcJprxr9C4yDqdxRtirrXIjW w/ZnMYBKMpSNA== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 668E4122535; Mon, 5 Dec 2022 15:12:23 -0500 (EST) In-Reply-To: (=?windows-1252?Q?=22Jo=E3o?= Paulo Labegalini de Carvalho"'s message of "Mon, 5 Dec 2022 08:24:37 -0700") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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:300938 Archived-At: >> 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. > 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. >> 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. Stefan