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 09:13:07 -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="19646"; 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 15:14:19 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 1rSe1D-0004po-4D for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Jan 2024 15:14:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rSe0t-0003GO-Du; Wed, 24 Jan 2024 09:13:59 -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 1rSe0r-0003GD-OD for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2024 09:13: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 1rSe0r-0000x8-GN for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2024 09:13:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rSe0w-0000ZT-Ha for bug-gnu-emacs@gnu.org; Wed, 24 Jan 2024 09:14: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 14:14: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.17061056142146 (code B ref 68664); Wed, 24 Jan 2024 14:14:02 +0000 Original-Received: (at 68664) by debbugs.gnu.org; 24 Jan 2024 14:13:34 +0000 Original-Received: from localhost ([127.0.0.1]:44804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSe0T-0000YY-RA for submit@debbugs.gnu.org; Wed, 24 Jan 2024 09:13:34 -0500 Original-Received: from mail-lj1-f170.google.com ([209.85.208.170]:55801) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSe0R-0000YL-Ga for 68664@debbugs.gnu.org; Wed, 24 Jan 2024 09:13:32 -0500 Original-Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2cc9fa5e8e1so59359971fa.3 for <68664@debbugs.gnu.org>; Wed, 24 Jan 2024 06:13:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706105600; x=1706710400; 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=g+96yF20asGEJT3GRFh7SrkeCh5h7Tm4SLrtNKyoVa0=; b=i0ENxufM9/ok8kHpF5dZjor/kMYXPEJt4T2q/VUs/oLrzUegxXbM7RaGwMt3nnS+gd z86XQZZK2M2dSmB3dTYEumgRvTh5WPRRJ4ZbwJYrM9ZgZNmnDRgSYCH3rL3/DAHKA5He EksvteA94ROEripeKFbsnm/q3FUk86WBSBfoseqNQXGcPr7Te3SBwCeCAmnT4s1KD+AY l50zwwVGj8DdvzuzHN/gqaCUqt3qmpQeUHHmRediXQc1v/tP2TZbSEyJCTi37qmmtFKe bOiEshqDEkhv9xwTrH2WBIQaVp1fmORd4iWyJvU4GeU1tue0CBphepA1LHRwnR3KmEU/ rf5g== X-Gm-Message-State: AOJu0YxSOiGiwRpxJL7cr/X7rkfDx1x9Ref53lefr1+VRsSFHazwnnTp uHBuSd77InjwCHPwE3tAfX1kcAkTL9XrRXminP5lztm3iDyz0v0WInGrmMtFxE18Rw== X-Google-Smtp-Source: AGHT+IFR0aLOgvdTERRQ/xyBDdwb6PH+NUxHmu1e7Rhq/WhCE3wTIgAC2KjMJ+b2WKVYAIMLOT4Rkw== X-Received: by 2002:a2e:a4af:0:b0:2cf:2008:36f6 with SMTP id g15-20020a2ea4af000000b002cf200836f6mr505075ljm.19.1706105599495; Wed, 24 Jan 2024 06:13:19 -0800 (PST) Original-Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com. [209.85.208.51]) by smtp.gmail.com with ESMTPSA id ez15-20020a056402450f00b0055a82fe01cdsm5542352edb.67.2024.01.24.06.13.19 for <68664@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jan 2024 06:13:19 -0800 (PST) Original-Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-559edcee47eso4775840a12.0 for <68664@debbugs.gnu.org>; Wed, 24 Jan 2024 06:13:19 -0800 (PST) X-Received: by 2002:aa7:d3d3:0:b0:55a:7db9:3b19 with SMTP id o19-20020aa7d3d3000000b0055a7db93b19mr1820527edr.11.1706105599163; Wed, 24 Jan 2024 06:13:19 -0800 (PST) In-Reply-To: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> 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:278785 Archived-At: 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 you= r expectations. The logic behind the current behavior is to first move betw= een siblings in the same level; if there=E2=80=99s no sibling to move acros= s 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 navigat= ion tactic, in addition to the existing three: nested, top-level, and restr= icted. > > If you are interested and able, maybe you can look into adding it to tree= sit--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.