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: Fri, 26 Jan 2024 20:26:38 -0800 Message-ID: References: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> 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="18317"; 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 Sat Jan 27 05:28:18 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 1rTaIj-0004Xq-PX for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Jan 2024 05:28:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTaIP-0002yX-8a; Fri, 26 Jan 2024 23:27:57 -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 1rTaIN-0002y1-8m for bug-gnu-emacs@gnu.org; Fri, 26 Jan 2024 23:27:55 -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 1rTaIN-0005yO-0P for bug-gnu-emacs@gnu.org; Fri, 26 Jan 2024 23:27:55 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rTaIT-0006CF-QN for bug-gnu-emacs@gnu.org; Fri, 26 Jan 2024 23:28:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Jan 2024 04:28: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.170632962823732 (code B ref 68664); Sat, 27 Jan 2024 04:28:01 +0000 Original-Received: (at 68664) by debbugs.gnu.org; 27 Jan 2024 04:27:08 +0000 Original-Received: from localhost ([127.0.0.1]:53255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTaHc-0006Ah-0w for submit@debbugs.gnu.org; Fri, 26 Jan 2024 23:27:08 -0500 Original-Received: from mail-yw1-x1134.google.com ([2607:f8b0:4864:20::1134]:53485) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTaHX-0006A9-EX for 68664@debbugs.gnu.org; Fri, 26 Jan 2024 23:27:06 -0500 Original-Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-6039716f285so2305507b3.2 for <68664@debbugs.gnu.org>; Fri, 26 Jan 2024 20:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706329611; x=1706934411; 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=DlaUATA9tH7jerXVH67MvR5nNM0QIfaX26S65F40DaM=; b=L54Nh+Y5TiCmaXpkJD3OeEH07dX9oaQO9VhZhQ7IwuSINwS3kDuq6p0rkAIGkNgD0D EpLIL7+QtSNcazw0UbbSemAygu07qLUHHE45/Mf6I+xrXw1etknLISas0sDGnqrupQug ci3/VgsGDJ2iv9t4bdKSOIgP2ifkqGR9u4a1KAU5Arb8Y0g+B06wsBOsYkW/ZK+dHpqc 68gR7Wpu+uX+dYZpEv9bPY4eOuQdxPjFUBURnMC+xvSSVRbBMLTeyqy1lrtN5N0+ranQ T9aSniw8hZ01X0dBVs3R7Jw3QMs5V3YXzdh6HhZBDkz352PJYByyxCxSl9Kfi5aDYksL PHNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706329611; x=1706934411; 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=DlaUATA9tH7jerXVH67MvR5nNM0QIfaX26S65F40DaM=; b=ocVPZt2FgREo5sNg4arFMyEqJtExEk/uYm8rFcKLgHAL1F8O6hqKF28yXew6NB6X6t MfdYV+gqMR8KsdMKnOqhIN6oT7zusJwvMSMvYKGDesSYaCdqOHoaTEBy3XeKdHiSdRhO ft47VkUsEpA4rL5GsNdkQN7t+UlBgTEZEN5SsrwP2Bsf+ZYo71s/Dt7RzEURFLmT46WO ZpmrIzb+0oXcvts51uW5M8J5f1ZwPxgygEP+g2jIJblUpOU+yhBKskKz3rcrUtZGPj9S i7MVbwELwlV1fVYxHK6FlmemOS1LonBB+/zEhCEyE1rjq+iTyvV6XNplwe/Xl+MHKgqV QCDg== X-Gm-Message-State: AOJu0YwAj9Kj/xn2MKMmUSVQlqQxknRi425WB3bA0lf8+lZaAY7xsFIp vX1O3wiV2wyfprCMWgyXWqVHh8seFisR9z8vWD5GuZ8ekP7iNuVm X-Google-Smtp-Source: AGHT+IFMhFj392WRoXV0UqPQKAMa2USVzzDaRbLaESRIVKxNRkjMFCWhY18fymnOO0zjVCA9yiH5tw== X-Received: by 2002:a0d:ca81:0:b0:602:a9ec:f03d with SMTP id m123-20020a0dca81000000b00602a9ecf03dmr967952ywd.52.1706329610824; Fri, 26 Jan 2024 20:26:50 -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 w19-20020a170902d3d300b001d787901410sm1665053plb.107.2024.01.26.20.26.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jan 2024 20:26:50 -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:278962 Archived-At: > On Jan 24, 2024, at 9:25 AM, Troy Brown wrote: >=20 > On Wed, Jan 24, 2024 at 9:13=E2=80=AFAM Troy Brown = wrote: >>=20 >> On Wed, Jan 24, 2024 at 1:29=E2=80=AFAM Yuan Fu = wrote: >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> If you are interested and able, maybe you can look into adding it to = treesit--navigate-thing or treesit-beginning/end-of-defun? >>>=20 >>> Yuan >>=20 >> 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. >>=20 >> 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. >=20 > 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. Yeah, I mean, I can definitely see the validity of the behavior you=E2=80=99= re describing. But I think the current behavior is equally valid. Right = now you can easily go to the previous/next sibling in the same level, = _and_ go to the beginning/end of the parent. You just need to press a = few more times. OTOH if you go straight to the parent, there=E2=80=99s = no way to go to siblings. As for mark-defun, I think it=E2=80=99s similarly equally valid to = either mark the next sibling or the parent. Right now mark-defun = doesn=E2=80=99t really have a notion of nested defun, we should upgrade = it to support nested defun like we did beginning/end-of-defun, either by = a toggle like mark-defun-tactic or let user control which defun to mark = interactively. Yuan=