From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#68664: 29.1.50; treesit defun commands broken with nested functions Date: Tue, 23 Jan 2024 22:29:40 -0800 Message-ID: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> References: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4002"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68664@debbugs.gnu.org, Daniel =?UTF-8?Q?Mart=C3=ADn?= To: Troy Brown Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 24 07:31:11 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1rSWn1-0000rJ-18 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Jan 2024 07:31:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rSWmq-0000iN-EU; Wed, 24 Jan 2024 01:31:00 -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 1rSWmo-0000hx-44 for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2024 01:30:58 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rSWmn-00009g-Rf for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2024 01:30:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rSWms-0001V5-EB for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2024 01:31:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Jan 2024 06:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68664 X-GNU-PR-Package: emacs Original-Received: via spool by 68664-submit@debbugs.gnu.org id=B68664.17060778065305 (code B ref 68664); Wed, 24 Jan 2024 06:31:02 +0000 Original-Received: (at 68664) by debbugs.gnu.org; 24 Jan 2024 06:30:06 +0000 Original-Received: from localhost ([127.0.0.1]:44325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSWlx-0001NV-Di for submit@debbugs.gnu.org; Wed, 24 Jan 2024 01:30:05 -0500 Original-Received: from mail-pg1-x52c.google.com ([2607:f8b0:4864:20::52c]:53322) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSWlv-0001MI-2W for 68664@debbugs.gnu.org; Wed, 24 Jan 2024 01:30:04 -0500 Original-Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-5cf1f4f6c3dso2620573a12.2 for <68664@debbugs.gnu.org>; Tue, 23 Jan 2024 22:29:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706077792; x=1706682592; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=a/42nfPNJGuzw1f/WP9inF/xOR0/jNESuaG0Y+87fJc=; b=lgIpCl1j2Ec5A69PqsJQOEC24nMXrH4/dyFDZQNPesACprNfmEwiTwDNAJzxsjgXwV LVQ5vflw1Yef3www8K5t2pIwjJysPOyiyu5UhY1xqhu0kBmaEgXGaDTY6YV6ENOBgiPE 0/VOMrLiyQxuXUpy/7HPWFu32mFC7GrRb3jTPBRyrZ/hZqVigrbs5DwEHgJy03hDNtfy xxz3iD8n8vbAguRB5ZlUrGXNv2MJ1bd8wPf7xfstyWIWPKpqbTB9ZB/Wg+h7XHJ70K5o sGwf+EqrCCjw8mLMfwr36+BypudBKpslILylvhN/+CvCLG0b2qHYoDHgBsfaG8j58V7x ljFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706077792; x=1706682592; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=a/42nfPNJGuzw1f/WP9inF/xOR0/jNESuaG0Y+87fJc=; b=G6GJLPFyMq0Q9PoiIiEEKA87U8c6J1r3cc5oASTL1LdnHQjSOfxQMKOzNhcUrTaLl6 BW1Iq92fLdrGMQObzNouMUxyGAHCA0EZZyOb1xOxwie3Q1PK922t4zZpoq0JNC8VbfqP lAwpUtqz5l/bb21olKsdBiA30jFUlnBrz0u4rATjN939N84v9gelHh+87z+/UKMFsqw3 kfE8cYfF+eKyAFbt6qj3ivk+W2DkRCplgQ3ufqKDGu/xqYOJIbAG5qtQVqjgaBHghj/w j/09cEy6khhIutxCo5L+b8rcMU42jQqPdLVlMl//mDvs2CrklBv+DYab5p8XmAi0J+KX IuVQ== X-Gm-Message-State: AOJu0Yz3Kbcj7wyk9qcwxkTd8cs3k3tgfkDr8P9cCItFYr/MNhUVIoK6 vz0TUDGurrPv9t0zXXFJmi14XkHJwVcYTvPuL3AqW9Z0G9yw1ETL X-Google-Smtp-Source: AGHT+IHNfClc2vj8D8IFpHrgJhQaQu8kw4uwlQuUkhQ/VAhP/VJDAwYhKQXPP1RA/fEpeAwV+ocvZg== X-Received: by 2002:a05:6a20:12c8:b0:19b:1da3:cb99 with SMTP id v8-20020a056a2012c800b0019b1da3cb99mr326782pzg.5.1706077791803; Tue, 23 Jan 2024 22:29:51 -0800 (PST) Original-Received: from smtpclient.apple (172-117-161-177.res.spectrum.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id v20-20020aa78514000000b006db18f59ac6sm12872887pfn.51.2024.01.23.22.29.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jan 2024 22:29:51 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.3731.700.6) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:278765 Archived-At: > On Jan 23, 2024, at 6:30 AM, Troy Brown wrote: >=20 > On Mon, Jan 22, 2024 at 7:32=E2=80=AFPM Daniel Mart=C3=ADn = wrote: >>=20 >> Troy Brown writes: >>=20 >>> I've noticed that "defun" related treesit commands do not appear to = work >>> correctly when nested functions are involved. I've seen this = behavior >>> in multiple languages and believe the problem is an issue in the >>> treesit.el library. >>=20 >> Customize the treesit-defun-tactic variable to 'top-level to ignore >> nested defuns in navigation commands. >=20 > But I don't want it to just go to the top-level, I want it to respect > the current > nesting level. If I insert yet another level in the example, and > point is within > the second level of nesting, I want it to move to the beginning and = end of that > nested function (i.e., "secondLevel" in the sample below when point is = on the > call to innerFunction). As mentioned in my original email, = python-mode does > respect the nesting level correctly, but python-ts-mode, and other = "ts" modes > that support nesting, don't respect it. The behavior is expected. But I can see that it doesn=E2=80=99t match = your expectations. The logic behind the current behavior is to first = move between siblings in the same level; if there=E2=80=99s no sibling = to move across anymore, move to the beginning/end of the immediate = parent, and so on. To get the behavior you want, we would need to add a fourth defun = navigation tactic, in addition to the existing three: nested, top-level, = and restricted. If you are interested and able, maybe you can look into adding it to = treesit--navigate-thing or treesit-beginning/end-of-defun? Yuan=