From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Troy Brown Newsgroups: gmane.emacs.bugs Subject: bug#68664: 29.1.50; treesit defun commands broken with nested functions Date: Wed, 24 Jan 2024 12:25:36 -0500 Message-ID: References: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> Mime-Version: 1.0 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="9496"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68664@debbugs.gnu.org, Daniel =?UTF-8?Q?Mart=C3=ADn?= To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 24 18:27:03 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 1rSh1j-0002DW-Gv for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Jan 2024 18:27:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rSh1e-0007UV-RS; Wed, 24 Jan 2024 12:26:58 -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 1rSh1c-0007UM-Up for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2024 12:26:57 -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 1rSh1c-0007kW-Mu for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2024 12:26:56 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rSh1i-0006Cj-0t for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2024 12:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Troy Brown Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Jan 2024 17:27:01 +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.170611716323761 (code B ref 68664); Wed, 24 Jan 2024 17:27:01 +0000 Original-Received: (at 68664) by debbugs.gnu.org; 24 Jan 2024 17:26:03 +0000 Original-Received: from localhost ([127.0.0.1]:46524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSh0k-0006Az-FD for submit@debbugs.gnu.org; Wed, 24 Jan 2024 12:26:03 -0500 Original-Received: from mail-ed1-f42.google.com ([209.85.208.42]:57826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSh0i-0006AZ-NV for 68664@debbugs.gnu.org; Wed, 24 Jan 2024 12:26:01 -0500 Original-Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-55c932f7fcbso2320572a12.3 for <68664@debbugs.gnu.org>; Wed, 24 Jan 2024 09:25:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706117149; x=1706721949; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0A5W660fM7xI2m1nUzdHqRm0ap6dMNOQSAIgLKK7sYE=; b=G1cfXf7HjFPBfRW6nnazqveNMxJb3aJ3+cxrRa2xNHd3zsn4VQpyv6IXDNAb5Ge73U h7GM5Ynj6Zd6F3OeYLxvsFsQceE+84O3gDG8EjjEgXOEGBe9uD3sAGnj9gPY433EQUpx fyLxS2a74DiBQFB1/9fuxqDw//CDJ+CmnVm4aoeGRVG7CCteBJgiWmFNaDs+AnHIBPI0 gYpXij80QVrBOucUbR9P2wc6sxsqLiKi/AK/YG8gwCX+Jb/5hB87qZqJh99WmJLgdJbI H0S0WuChYIRkzBjVLvwbkEtIS1TMAswqIuzDI2sBbSYtbqmgnq2MvhshCxrDVrMCR5L9 7a3Q== X-Gm-Message-State: AOJu0YxynKB+HZk1b78zn2pGbUpaREbjYfsyWJCHRg8AGedrR4OoCh41 1cIm8LdHdulfNLyqz5w+XLlO17qwgU0e/kM7bzduDd2atJ+afQPbbiBzPw2L48v3YA== X-Google-Smtp-Source: AGHT+IGtFpbEZkmkAwTFKtpmPHlllyvHKfl5bFSbwYZZ9mU2/8L4pFzl6G5E50VdwssjRlSgviO3Ag== X-Received: by 2002:a05:6402:518b:b0:55c:7afd:6075 with SMTP id q11-20020a056402518b00b0055c7afd6075mr2274450edd.66.1706117149009; Wed, 24 Jan 2024 09:25:49 -0800 (PST) Original-Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com. [209.85.208.41]) by smtp.gmail.com with ESMTPSA id n13-20020a05640204cd00b0055971af7a23sm11427964edw.95.2024.01.24.09.25.48 for <68664@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jan 2024 09:25:48 -0800 (PST) Original-Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-55a179f5fa1so6820052a12.0 for <68664@debbugs.gnu.org>; Wed, 24 Jan 2024 09:25:48 -0800 (PST) X-Received: by 2002:aa7:cd59:0:b0:557:77f:9be7 with SMTP id v25-20020aa7cd59000000b00557077f9be7mr1907834edw.61.1706117148143; Wed, 24 Jan 2024 09:25:48 -0800 (PST) In-Reply-To: X-Gmail-Original-Message-ID: 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:278807 Archived-At: On Wed, Jan 24, 2024 at 9:13=E2=80=AFAM Troy Brown = wrote: > > On Wed, Jan 24, 2024 at 1:29=E2=80=AFAM Yuan Fu wrote= : > > > > The behavior is expected. But I can see that it doesn=E2=80=99t match y= our expectations. The logic behind the current behavior is to first move be= tween siblings in the same level; if there=E2=80=99s no sibling to move acr= oss 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 navig= ation tactic, in addition to the existing three: nested, top-level, and res= tricted. > > > > If you are interested and able, maybe you can look into adding it to tr= eesit--navigate-thing or treesit-beginning/end-of-defun? > > > > Yuan > > I find it quite odd that this is the expected behavior. Per the Emacs > manual (section "Moving by Defuns"), I expected the point to be moved > to the "innermost defun around point", since treesit-defun-tactic is > set to "nested", as that is precisely what is documented there. I > interpret "innermost defun around point" to mean the innermost defun > that encompasses point. Additionally, the documentation strings for > treesit-beginning-of-defun and treesit-end-of-defun indicate that they > are a tree-sitter equivalent of the beginning-of-defun and > end-of-defun commands respectively. If so, and since they are mapped > to the same key bindings in the tree-sitter modes, shouldn't the > expectation be that they behave the same way as the non-tree-sitter > commands? If not, people transitioning between the non-tree-sitter > mode and the tree-sitter mode are in for a surprise when the commands > behave differently. > > With the current behavior there is no way to move the point directly > to the beginning of the function without moving through all of the > nested functions first, which could be significant. When you say the > behavior is to "move between siblings in the same level", should the > level refer to where point is, or to the level corresponding to the > function encompassing the point? I think it probably makes sense to > move between siblings if you are at a function boundary (there is a > function immediately before or after the point), but if you are > already deep in a function, I think it makes sense to first move to > that function's begin/end before attempting to move between siblings. > I believe this behavior would be consistent with the non-tree-sitter > modes and expectations based on the description in the manual. To add further support to my belief that the current implementation is not the expected behavior, consider how the current implementation behaves when used with mark-defun. When the point is on the call to innerFunction and I execute "M-x mark-defun RET", the nested function following the point (i.e., innerFunction2) is selected rather than the function containing point. For comparison, the non-tree-sitter python-mode behaves correctly and selects the function containing point, not the next nested function.