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: Sat, 27 Jan 2024 20:03:30 -0800 Message-ID: References: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> <86a5or9qpq.fsf@gnu.org> 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="25768"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68664@debbugs.gnu.org, Troy Brown , mardani29@yahoo.es To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 28 05:04: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 1rTwOx-0006S6-4J for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 28 Jan 2024 05:04:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTwOm-0004dB-Ch; Sat, 27 Jan 2024 23:04: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 1rTwOg-0004cc-GY for bug-gnu-emacs@gnu.org; Sat, 27 Jan 2024 23:03:54 -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 1rTwOg-0006Xq-7v for bug-gnu-emacs@gnu.org; Sat, 27 Jan 2024 23:03:54 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rTwOn-0008Dg-LI for bug-gnu-emacs@gnu.org; Sat, 27 Jan 2024 23:04: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: Sun, 28 Jan 2024 04:04: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.170641464031589 (code B ref 68664); Sun, 28 Jan 2024 04:04:01 +0000 Original-Received: (at 68664) by debbugs.gnu.org; 28 Jan 2024 04:04:00 +0000 Original-Received: from localhost ([127.0.0.1]:56253 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTwOm-0008DR-3K for submit@debbugs.gnu.org; Sat, 27 Jan 2024 23:04:00 -0500 Original-Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]:52598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTwOh-0008D8-Fz for 68664@debbugs.gnu.org; Sat, 27 Jan 2024 23:03:59 -0500 Original-Received: by mail-ot1-x32d.google.com with SMTP id 46e09a7af769-6e125818649so16061a34.1 for <68664@debbugs.gnu.org>; Sat, 27 Jan 2024 20:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706414622; x=1707019422; 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=WjpFNCdQdWAoo+wPGPK9AtcVQsNvzDatLBjmlik/tnw=; b=nFGvRgYGeGcUr2kduC/BQFkRnOi2k+0HWF4HeTDlm5BkWprLIcrmxSoFHlZJo+MvI9 ONGCigxLrYU3/TeFsCCCzYyoaifp5Mb4O0ZeyFdRahMQ7LLUnChb+F4zn3JhWQZykCfV h84egwKJNcyv7J2uZ7gc2dfTegV4q0GFP6CTO8WFgxaxpveih/5fsQLFBGz4CRTOexJz K3ftQygX04pzdRCcn5NQvkHX3nZIUEnO09Dtj8THxT54KEfevLuBvhup4fyTyWpaoQT5 9PNQfhFXGa/ctKt+CEyh4vnIWvw3ygMBtFP5wahmvckCayhcZVCzCphpcaPGSl9XLJjy 6NWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706414622; x=1707019422; 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=WjpFNCdQdWAoo+wPGPK9AtcVQsNvzDatLBjmlik/tnw=; b=JKQpAGQnsnnoDuPkULL+Qs0PkA8niMuZsN/dTXGyBZZqtd55HMcWfR/H6FUblo8RSV CLCsX3kdNmvGSW/Qrkh6iRw2WbAy4lS15ne2hHpggqzEn3j/YkngBL0Kr9/d2avxOyQ9 kjm8nxSkbvXp8Euf3ONHjD1gqJqyorD1MX0Hib5AIg8zOzNNFLnefpI5AAd3vAOXHp2p oetaM9KHGOMpqG9FhJbzgqgKWdAPH9B4B7l2lZan1Npid9EpQqdlstsHFcvfdwU6+otU d82iqvZsPob8HwAUdxWdXW1Z3qGuPdVxoV5OI8gcGM/lJ6Qx7UnKtq5hr35cXGjkoqf2 7RyA== X-Gm-Message-State: AOJu0Yz6GtzfKs+f0i3qgnLDEvxWeDUQlPVcpPFRWJbv+KIXdQ+3xc4s r1e+G+d52HXcQZqBNfbi1rghng4HNKkr89mDCAyhwY9pnPQkHSal X-Google-Smtp-Source: AGHT+IFpmGi+FL7U7uvv7ZJnGjuY56zXczTaAXgJc6PK/ibBqR5WvnreXr4II/8X/TwBRlsmKFBTSw== X-Received: by 2002:a05:6358:89d:b0:178:6bb9:427d with SMTP id m29-20020a056358089d00b001786bb9427dmr506250rwj.45.1706414621995; Sat, 27 Jan 2024 20:03:41 -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 jh19-20020a170903329300b001d7724c24besm3101751plb.9.2024.01.27.20.03.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jan 2024 20:03:41 -0800 (PST) In-Reply-To: <86a5or9qpq.fsf@gnu.org> 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:279051 Archived-At: > On Jan 26, 2024, at 11:32 PM, Eli Zaretskii wrote: >=20 >> Cc: 68664@debbugs.gnu.org, Daniel Mart=C3=ADn >> From: Yuan Fu >> Date: Fri, 26 Jan 2024 20:26:38 -0800 >>=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. >>=20 >> Yeah, I mean, I can definitely see the validity of the behavior = you=E2=80=99re 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. >=20 > Maybe we could support both behaviors via specially-valued prefix > arguments? Like "C-u" means something, "C-u C-u" means something > else, etc.? Beginning/end-of-defun already take a numerical interactive arg, unless = I missed something we can=E2=80=99t add another. If we want to change = behavior interactively we would need something more elaborate, maybe = transient maps. >=20 >> 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. >=20 > Same here. >=20 > WDYT? Same for mark-defun, it also has an interactive arg already. I feel like I missed something, surely you know they already have = interactive args :-) Yuan