From unknown Tue Jun 17 20:17:14 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#68664 <68664@debbugs.gnu.org> To: bug#68664 <68664@debbugs.gnu.org> Subject: Status: 29.1.50; treesit defun commands broken with nested functions Reply-To: bug#68664 <68664@debbugs.gnu.org> Date: Wed, 18 Jun 2025 03:17:14 +0000 retitle 68664 29.1.50; treesit defun commands broken with nested functions reassign 68664 emacs submitter 68664 Troy Brown severity 68664 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 22 18:11:05 2024 Received: (at submit) by debbugs.gnu.org; 22 Jan 2024 23:11:05 +0000 Received: from localhost ([127.0.0.1]:41890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rS3RY-0002pL-U0 for submit@debbugs.gnu.org; Mon, 22 Jan 2024 18:11:05 -0500 Received: from lists.gnu.org ([2001:470:142::17]:46386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rS3RU-0002oi-Eu for submit@debbugs.gnu.org; Mon, 22 Jan 2024 18:11:04 -0500 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 1rS3RK-0003Hj-Ib for bug-gnu-emacs@gnu.org; Mon, 22 Jan 2024 18:10:50 -0500 Received: from mail-ej1-f52.google.com ([209.85.218.52]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rS3RI-0007Zr-NQ for bug-gnu-emacs@gnu.org; Mon, 22 Jan 2024 18:10:50 -0500 Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-a30359b97a8so182347766b.0 for ; Mon, 22 Jan 2024 15:10:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705965046; x=1706569846; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=qzHdaFtAZsmIKFhY0c0+/fflDT8Ra+oMMeK1SKLFPpA=; b=eEvqVDAPqxhEwltDxypqsxFQS6VGnUApDqTJXGtE9W9pdsWFA1JFmuZo/Du6DTsp7A 2wZPJ1rdQ+rWFMD6dGANLs5qQtPRoA+qNq533V7Pocm/GVggiOTdyTRf+pG92TWvvOMl LNlMnRZITJCEmmpzqNMQuvtpKTySwQL06HHBXSy80bPJdHwpwG3JARk0XJE0yZiAHlFV 6q7cfQwntJWk0veT8N/ViSXoWNw+H7Lka6MnYSQ5vs8ClOSsBw44zPUjBM7xLa+fYKKg 005JSqmD2I27uls2uCq4Gi6+eLdHVzgSCZGYk3e5zJBbHeABb01DHXdW95KJ9yJiEJhu zbAQ== X-Gm-Message-State: AOJu0YwUoDiaTzI1NVmDFDjjX4hpSqwWnZ1+PqiA74iMI/mhtvRv1iJb fZnhYpi5189NJmfPZeLdRDploCypo7lfy2kSJufgG8LJxr7jbzg46pOPV8KD5e/3AKUx X-Google-Smtp-Source: AGHT+IGH+PhfokLo1kEs2vwiA87FPz14v7bpFm8eVp3DFgecXHiDyAVvw88YAc5NJpJBOHtLVSfuUg== X-Received: by 2002:a17:906:bf47:b0:a2f:7ba2:2fe0 with SMTP id ps7-20020a170906bf4700b00a2f7ba22fe0mr2844425ejb.79.1705965046434; Mon, 22 Jan 2024 15:10:46 -0800 (PST) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com. [209.85.128.46]) by smtp.gmail.com with ESMTPSA id ks19-20020a170906f85300b00a2b086c29e1sm13799990ejb.127.2024.01.22.15.10.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jan 2024 15:10:46 -0800 (PST) Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-40eb2f3935eso4459255e9.2 for ; Mon, 22 Jan 2024 15:10:46 -0800 (PST) X-Received: by 2002:a7b:c8c9:0:b0:40e:4683:9d69 with SMTP id f9-20020a7bc8c9000000b0040e46839d69mr2700953wml.132.1705965045909; Mon, 22 Jan 2024 15:10:45 -0800 (PST) MIME-Version: 1.0 From: Troy Brown Date: Mon, 22 Jan 2024 18:10:34 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: 29.1.50; treesit defun commands broken with nested functions To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=209.85.218.52; envelope-from=troy.s.brown@gmail.com; helo=mail-ej1-f52.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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 [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (troy.s.brown[at]gmail.com) -0.0 T_SCC_BODY_TEXT_LINE No description available. 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) 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. According to the Emacs manual section "Moving by Defuns", the beginning/end-of-defun commands should "... find the beginning and end of the innermost defun around point". I don't see this behavior with the corresponding treesit-beginning-of-defun and treesit-end-of-defun commands. The following example uses python-ts-mode to demonstrate the issue. --8<---------------cut here---------------start------------->8--- # -*- mode: python-ts -*- def outerFunction(text): text = text def innerFunction(text): print(text) innerFunction() def innerFunction2(text): print(text) innerFunction2() --8<---------------cut here---------------end--------------->8--- To reproduce the issue, place point on line 9 (i.e., the call to "innerFunction"). When point is at this location, I've noticed incorrect behavior for the following commands: M-x treesit-beginning-of-defun RET Moves point to the beginning of the "innerFunction" function (line 6) instead of the beginning of the "outerFunction" function (line 3). M-x treesit-end-of-defun RET Moves point to the end of "innerFunction2" function (line 13) instead of the end of the "outerFunction" function (line 15). For comparison, the buffer can be switched to python-mode and the above repeated with the non-treesit versions of these commands to demonstrate that the regular python-mode does work as expected. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 22 19:32:34 2024 Received: (at 68664) by debbugs.gnu.org; 23 Jan 2024 00:32:34 +0000 Received: from localhost ([127.0.0.1]:41991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rS4iO-00052L-CB for submit@debbugs.gnu.org; Mon, 22 Jan 2024 19:32:34 -0500 Received: from sonic305-21.consmr.mail.ir2.yahoo.com ([77.238.177.83]:34547) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rS4iI-000523-Nk for 68664@debbugs.gnu.org; Mon, 22 Jan 2024 19:32:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.es; s=s2048; t=1705969935; bh=IlZVsIXtj4bRzXSQAHPVYpDnzRSa9kjMK6D3t8iW3vQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=BPZ8VlH59RBhYzAhGO9AM5NVkkfswW+LNnJpC215iJTcU5HpA6UzkAs0hvYbsO+UC6eNa1h4HNbRSoC8KUrFFuEt9hbL5M6ipbP0ZRnNEwc7D5oNiiF0NNjiGANRa20cnN2d7zjgVxeQRXAEgSo1Q0nHWkRWZ/RGGm6ScAVqtmSnvpvj2Ep/iV5Wnsl08Ejfx0Hb5b7+to9fw5SEGWoBuGUkNQsonzRciQo40iXgXb5gcI0KvDnGv9XO5Coj8SMCmDqkXsIPelXKbvf67ZRnwZxhU4lyxyZou4V97VaSsRAiPanM8o6IfGolsksGIJao1JaWTqJ0K58NqJ6cDJvQhg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705969935; bh=7ZfFe93taX38371z+T93VSEPU8NZvhKz3b++T0w8DIx=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=aHar7dX3yQyJNeaVnrLEEyawGWhf5Gf0w1qxKb/xNj0g2aBfbHBI88ZLOvqWH4FzU8FbU9gkpkhYRz/wpwyzWTskJ3a+Mvn834Qh8iepbtyqYlzE0l5tx0xeJq/txy9KkMvU+Q+YUzRkYaLrhQK/9rXHFkcmmZU7QohW4kVh4IvLisqLgfel/x12b2Sc+oUkQ7nEFB1TB74/BeU9gjk2q3f62B6ftqNlBe0WMOhKK+BsD6eH7Wpe/09oWtnMoiCj1/OkcQrPxlZz33jTM6EgjNLqK8jON77VBIz6zc7mAu8pKdZMEwZWVFLTUGtZXLQT7vXaciQE1Aidc/fCPE8DRA== X-YMail-OSG: NepH21cVM1kvFFbMiRlMSq6vBPstyhMCSo8eTPbTw5AsxNT15bu11kWc5sVvT72 wmxPNzPBmFWx2k26rWELECckx1Q1b8SSrY5JDeauFg9z7ToXyLleK3WNmWgsBea8zFA_fIY8Acos 2zzdqgZqLPs02gHION6RxHkErdnc3wI1PpCtrevn._V9CvglZr9P7OTSq3MuCTE2qxLzAc0Hf8PB dwm86I2U0vawGiTpCY9xJuRkotE82aEI0x29UoWKli2gV_H9emRWqunNuLaeCGjNzEWtZy7fifZL nj41P5mXjTvqBfeK8VRbFVmK1596b3b9QF64JD20MCrUhMVdnjPRIUIimt8pH_xslpdk7qQGp2iV alRSDhn7iRGJ_qjjg6lInbv6h5Hmr2Ce8oBmJER9ZR0kwiCu8TAaMUkU3B.0SbbHxfjruSU_1gnw kbYfD3C7UvTScoLVZANcRpP.hgfdjQVZojf.UNLZ0ecYuMc5FZgbTx_lY9h2Mjm9jNCLZ6s3YQHt fOJasEDZKiGWSlWbpaI9SNKxL6XiCQoVXOafo3lncUtI9ySpA3rR9dL4otQhiR.8Cx1FvGGAdyR7 .8aiQF.P.EqFKSjUHklYtP2Au4KMTpsKrFLmqrUmnc9Orz7Mn2d5YHPk9kaIVNiah2VWqX1ONeP1 P4Qpz7m1n8Cw7MKIwmboLLEyAHB0y3taBUr2AXWGL.mhqtSXEVZro7rtd7jGw.RpH2AfFUAExBwz ty8ffDQz888m7wfqQDHm51ysw45bjdlqSDeoZH6mzdkMIwPY2oHezccPots3vg4E8vU78ksbhJ2y g.oeJRyQjbS0nHItxYC7kVLvj20nEEPVa85CkQNzi13nU.IA7g59aNjOedKd9PE8AZJ98w6X49xA tvx.yBfIpUv3KLQc2bcgf4p_Tzm_lEkqqyWKR1gQrSJ.f2ORAeM06ihMQGVdqdNxu47d0IwUmQ2S gYy7Bi8E7u64BWwmVUyUXl3I2WhZi0gAWRgfK6.cHz8zUryGFQC3LRtxJ_LnhoaTCDfsEZCpOljH ZlcE4eWxwc2aAutqvgF1g.OEMRhsbHaLHxXPxO5mBBQGW4hORr6Aik0DpW8klpZp.L5T85fkUWjT I3KupXa1RCo..wJAxvvgfob6rlaYcBuzcRy7NjIwGnUCGT1C0.9.7klduF8BjEzh08ZbaOrcra26 NJOUk5LCZvmz7MXDMi28vBIJMpK.L80cxRz1aZE2Q7xhU5vNyABFzK0ri9D.AwFkFr5MaCbnCXE8 S2ERViIo1AuNb9MuqpJHp4GAYVW3OPSeBBMWjbtKXGPffODh7_xTtzK62w6ckMMImkNV8K_OgP6u EG9pjTSc149MFE1cF2hN5TVE6w4387TqHIk.zd.dXoVrOpd.e3f_xbUYvnK55YNkVzdc.YEC8rEG 5xhXyJgwqgYlipmt0TAToLtqLPtRxYgpVfF5gOSd.XvEcAPXLryIHLEgtijR7NK1e7COoFQn7Vto fv7Rfp_C.gL9I9H9k3k_hMMzajmtiee3K0Dr7mFE.ejx2j2vXDJnt_q21W5.pJl9larnoQduFz6z APNjtfTuPa2ZFCR3WgWXY9zQWvk1WA8GpWK5AhhOPuP9cpTHrUyV0qYrnj5UgUSA4Za3sHz2VA6X 5uN6dzwBItjE6mrcKjky8vyFApJNt7py8XhrLa01RwTWjgfG2aADhVr_jHqYXH6.ipAi2oIzjQIE IaiE6xqF7AseJE3BptC9wnPansxIde9rv6Hx5uHYgoefDuziBuR_YF5x.IhnvsgKnVEKl..cvSKX ugMArJAJOBVLPFjVNcWB3nXOhpSxHEpgAbm2tVYeyGN4mT2o67SZsmPN3w0mfNXEyl7OmAOUoHFL mcBB1IukpEngOQF49ITdNCSBFP2FJU05RXVmrBJAtON10tylSECFQ_uIQ5lBU8qqLeN.7JnoG9_7 APxTCmlL2kLd10I1AiZaqEAFsTNSBa39yj7OCw46mZ16_a4YohMELMLVLlD7Nk9lLMLUEnwX1u_1 LuRjo8k3WB8VK7wccwiOZn2PjUGHS3zD16Gl4YV9lfVkUjUILzgDN1.YTa_ypjvq8seQhWdJlp0L OeysnQxJVnrOB19zbnleCe_kIKvcHzUt3KgaJYmSYgZhr9VAtAsnTPd426NC_nZUOB98vddS.Phh tr1IzP9F8Y_rfBQ47VvWwNH7Nv6uy3GjuhIkvgmv8Xkr0NSCmLHc3rdjtgEFEVBev7YXcTf9zWpk zqSB.NJeiw057iw7rq5YRB8RNNrGvwGZjwEDF8ekV0LuKtA-- X-Sonic-MF: X-Sonic-ID: c7fee34f-0410-4266-b97c-0c353a94fb08 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ir2.yahoo.com with HTTP; Tue, 23 Jan 2024 00:32:15 +0000 Received: by hermes--production-ir2-7cc8d8ff75-6xrwx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bfeec9e11fff09819375f23a75a31920; Tue, 23 Jan 2024 00:32:12 +0000 (UTC) From: =?utf-8?Q?Daniel_Mart=C3=ADn?= To: Troy Brown Subject: Re: bug#68664: 29.1.50; treesit defun commands broken with nested functions In-Reply-To: (Troy Brown's message of "Mon, 22 Jan 2024 18:10:34 -0500") References: Date: Tue, 23 Jan 2024 01:32:11 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.22027 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 388 X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 68664 Cc: 68664@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Troy Brown writes: > 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. Customize the treesit-defun-tactic variable to 'top-level to ignore nested defuns in navigation commands. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 23 09:31:16 2024 Received: (at 68664) by debbugs.gnu.org; 23 Jan 2024 14:31:16 +0000 Received: from localhost ([127.0.0.1]:42531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSHo3-0008DE-PS for submit@debbugs.gnu.org; Tue, 23 Jan 2024 09:31:16 -0500 Received: from mail-ed1-f46.google.com ([209.85.208.46]:51700) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rSHo0-0008D0-Tz for 68664@debbugs.gnu.org; Tue, 23 Jan 2024 09:31:14 -0500 Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-55790581457so5962398a12.3 for <68664@debbugs.gnu.org>; Tue, 23 Jan 2024 06:31:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706020262; x=1706625062; 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=iTZ8cxH7eShes12Y7BjoaQpv9rn6spGODNxJS6qRiuo=; b=UrmZKbqPvjxB7SVOAE1mPu+BynepfAPPntFTsJtKKf7flPxquKjPoGh/YkQYkuaMbI KJpOq7CjNlR+iQupS44WQmBY0D4MtYK6CIDU0A11lkvbamt9YyASZQLp2yeJEB3W4vFK GflNbfP8ovgarNCRPdr1VqpsiVoOxBfjmp9MbPUIs//RckNZ+4kZkFrSYK3K70/0X9Au y8S6R/FYMyAbmp5qyvYo0mca5zQHPsAu/DNMOquxvh3knudtR/N6s2lfAtt7D97k7jAC 2l4homIIEWsROkDwkHb7bNyL2HhxEQm3IANj5UDx+Bkp29HKFJVmLeS158FruHk14uBW XRkQ== X-Gm-Message-State: AOJu0YwoyiH9PMildy+K0HDPhyLTfi1wqqKphWDUiQQ+IfxpkIq7MFuk p3cnyam6J/czUd3M662kocJbpHBTvWiOTmEBA3yKV0aPKpJFZctw6WB/TDMNqc/Kfxgm X-Google-Smtp-Source: AGHT+IGsnzpSAjY2DqXbcu7bo5ZpT7YTdHZtuDoq8juTdBkW3Dw/u0rRFeC27MZzk/MXn9WrKUZiXg== X-Received: by 2002:a50:a6db:0:b0:557:fe5:a682 with SMTP id f27-20020a50a6db000000b005570fe5a682mr886373edc.80.1706020261515; Tue, 23 Jan 2024 06:31:01 -0800 (PST) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com. [209.85.208.45]) by smtp.gmail.com with ESMTPSA id q20-20020aa7da94000000b00559f32cc081sm3631966eds.57.2024.01.23.06.31.00 for <68664@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jan 2024 06:31:00 -0800 (PST) Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-55a8fb31fc2so3517187a12.0 for <68664@debbugs.gnu.org>; Tue, 23 Jan 2024 06:31:00 -0800 (PST) X-Received: by 2002:a05:6402:1c0e:b0:558:d960:e2e7 with SMTP id ck14-20020a0564021c0e00b00558d960e2e7mr889397edb.40.1706020260587; Tue, 23 Jan 2024 06:31:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Troy Brown Date: Tue, 23 Jan 2024 09:30:49 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: bug#68664: 29.1.50; treesit defun commands broken with nested functions To: =?UTF-8?Q?Daniel_Mart=C3=ADn?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 68664 Cc: 68664@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On Mon, Jan 22, 2024 at 7:32=E2=80=AFPM Daniel Mart=C3=ADn wrote: > > Troy Brown writes: > > > I've noticed that "defun" related treesit commands do not appear to wor= k > > 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. > > Customize the treesit-defun-tactic variable to 'top-level to ignore > nested defuns in navigation commands. 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 t= he call to innerFunction). As mentioned in my original email, python-mode doe= s respect the nesting level correctly, but python-ts-mode, and other "ts" mod= es that support nesting, don't respect it. --8<---------------cut here---------------start------------->8--- # -*- mode: python-ts -*- def outerFunction(text): text =3D text def secondLevel(text): print(text) def innerFunction(text): print(text) innerFunction() def innerFunction2(text): print(text) innerFunction2() secondLevel() --8<---------------cut here---------------end--------------->8--- From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 24 01:30:05 2024 Received: (at 68664) by debbugs.gnu.org; 24 Jan 2024 06:30:06 +0000 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 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 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) 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) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: bug#68664: 29.1.50; treesit defun commands broken with nested functions From: Yuan Fu In-Reply-To: Date: Tue, 23 Jan 2024 22:29:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> References: To: Troy Brown X-Mailer: Apple Mail (2.3731.700.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68664 Cc: 68664@debbugs.gnu.org, =?utf-8?Q?Daniel_Mart=C3=ADn?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > 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= From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 24 09:13:34 2024 Received: (at 68664) by debbugs.gnu.org; 24 Jan 2024 14:13:34 +0000 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 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 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) 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) 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) MIME-Version: 1.0 References: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> In-Reply-To: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> From: Troy Brown Date: Wed, 24 Jan 2024 09:13:07 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: bug#68664: 29.1.50; treesit defun commands broken with nested functions To: Yuan Fu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 68664 Cc: 68664@debbugs.gnu.org, =?UTF-8?Q?Daniel_Mart=C3=ADn?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 24 12:26:03 2024 Received: (at 68664) by debbugs.gnu.org; 24 Jan 2024 17:26:03 +0000 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 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 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) 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) 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) MIME-Version: 1.0 References: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> In-Reply-To: From: Troy Brown Date: Wed, 24 Jan 2024 12:25:36 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: bug#68664: 29.1.50; treesit defun commands broken with nested functions To: Yuan Fu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 68664 Cc: 68664@debbugs.gnu.org, =?UTF-8?Q?Daniel_Mart=C3=ADn?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 26 23:27:08 2024 Received: (at 68664) by debbugs.gnu.org; 27 Jan 2024 04:27:08 +0000 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 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 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) 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) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: bug#68664: 29.1.50; treesit defun commands broken with nested functions From: Yuan Fu In-Reply-To: Date: Fri, 26 Jan 2024 20:26:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> To: Troy Brown X-Mailer: Apple Mail (2.3731.700.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68664 Cc: 68664@debbugs.gnu.org, =?utf-8?Q?Daniel_Mart=C3=ADn?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > 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= From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 27 02:32:36 2024 Received: (at 68664) by debbugs.gnu.org; 27 Jan 2024 07:32:36 +0000 Received: from localhost ([127.0.0.1]:53363 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTdB6-0003MB-65 for submit@debbugs.gnu.org; Sat, 27 Jan 2024 02:32:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53400) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTdB4-0003Lu-DJ for 68664@debbugs.gnu.org; Sat, 27 Jan 2024 02:32:35 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTdAq-00017g-9R; Sat, 27 Jan 2024 02:32:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=kKYPk8gc9Q6p0fgPl8mowezfYC71R/9p7whIey58fTE=; b=BPIclokTlulqHE4EFPpj oXT+/CPLmH5eYucORUAhJ0qhWqKZAayyMfjdNQu61t114NWbKAaLgvaTTQSXceN1MnbfJuVlN1sNh OkzSsCwOubknI3zjHb3sBpgcxIWVkH+zrXJh4Y4jIq7S/0464DJphmHz+9PSQC3F4+e8dpzzUpZaP +R+iibopMg4VX/1TxuF8eGmU8L2RClaUDab7cVASY+QXYOT/VuS+BWSxiBNxCwAT99mkAeg8CTxCF qHVKiJGvenFUfD/itZatGRjndZImhqcN3iICvzkmKdvMMBJyvbJ/E9XbcUW1x73C/hxq2cNPvZxmU kbhIWe9nC/3aBg==; Date: Sat, 27 Jan 2024 09:32:17 +0200 Message-Id: <86a5or9qpq.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: (message from Yuan Fu on Fri, 26 Jan 2024 20:26:38 -0800) Subject: Re: bug#68664: 29.1.50; treesit defun commands broken with nested functions References: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68664 Cc: 68664@debbugs.gnu.org, brownts@troybrown.dev, mardani29@yahoo.es X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 68664@debbugs.gnu.org, Daniel Martín > From: Yuan Fu > Date: Fri, 26 Jan 2024 20:26:38 -0800 > > > 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’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’s no way to go to siblings. Maybe we could support both behaviors via specially-valued prefix arguments? Like "C-u" means something, "C-u C-u" means something else, etc.? > As for mark-defun, I think it’s similarly equally valid to either mark the next sibling or the parent. Right now mark-defun doesn’t 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. Same here. WDYT? From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 27 23:04:00 2024 Received: (at 68664) by debbugs.gnu.org; 28 Jan 2024 04:04:00 +0000 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 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 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) 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) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: bug#68664: 29.1.50; treesit defun commands broken with nested functions From: Yuan Fu In-Reply-To: <86a5or9qpq.fsf@gnu.org> Date: Sat, 27 Jan 2024 20:03:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> <86a5or9qpq.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3731.700.6) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68664 Cc: 68664@debbugs.gnu.org, Troy Brown , mardani29@yahoo.es X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 28 01:53:56 2024 Received: (at 68664) by debbugs.gnu.org; 28 Jan 2024 06:53:56 +0000 Received: from localhost ([127.0.0.1]:56385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTz3E-0005av-5r for submit@debbugs.gnu.org; Sun, 28 Jan 2024 01:53:56 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTz3B-0005ad-LT for 68664@debbugs.gnu.org; Sun, 28 Jan 2024 01:53:54 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTz2y-0000H7-4n; Sun, 28 Jan 2024 01:53:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=DWNwoursNn893fV0DQ1d5ElixV2ICfZkEVYE7nCw38E=; b=Ze5zxb3tuXgiArmdFaSw JBvoqWFQwamYXjiqg4dk51+NrwZInwI6avp6NyVLpKITNEsjCscUGXPqSio442He5B6nQ8aR+t8he GeE1fCKNfHFhz1dIgoVUs4dusrA/1r2/S2DPvRlTOMYGdD4xbw5NHK6TnJXzyq+imOsgQxYJuF2Hy iWO5LbmCDq9UEcR6NR0QFr1+yGwAH85e6f1F6JLfa2QK8FUqAcb2MreZvSWwlQwAnGhqZzQ9nlkyO 55YrZTVtS+8gyTvdDccDj9BuMDV4+ugUIo/j+0qJeqn1vOJuq3pfrAecmv4N0H7dGHCmonK2BhvSx coyauRpsKBwXBw==; Date: Sun, 28 Jan 2024 08:53:38 +0200 Message-Id: <86r0i254p9.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: (message from Yuan Fu on Sat, 27 Jan 2024 20:03:30 -0800) Subject: Re: bug#68664: 29.1.50; treesit defun commands broken with nested functions References: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> <86a5or9qpq.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68664 Cc: 68664@debbugs.gnu.org, brownts@troybrown.dev, mardani29@yahoo.es X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Yuan Fu > Date: Sat, 27 Jan 2024 20:03:30 -0800 > Cc: Troy Brown , > 68664@debbugs.gnu.org, > mardani29@yahoo.es > > > 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’t add another. If we want to change behavior interactively we would need something more elaborate, maybe transient maps. > > > > >> As for mark-defun, I think it’s similarly equally valid to either mark the next sibling or the parent. Right now mark-defun doesn’t 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. > > > > Same here. > > > > 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 :-) "C-u" and "C-u 4" are not the same, and can be distinguished by the function's body, right? From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 28 02:30:06 2024 Received: (at 68664) by debbugs.gnu.org; 28 Jan 2024 07:30:06 +0000 Received: from localhost ([127.0.0.1]:56423 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTzcD-0006Z6-IT for submit@debbugs.gnu.org; Sun, 28 Jan 2024 02:30:06 -0500 Received: from mail-pg1-x52a.google.com ([2607:f8b0:4864:20::52a]:55481) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTzc9-0006Y7-NR for 68664@debbugs.gnu.org; Sun, 28 Jan 2024 02:30:03 -0500 Received: by mail-pg1-x52a.google.com with SMTP id 41be03b00d2f7-5ce9555d42eso1530185a12.2 for <68664@debbugs.gnu.org>; Sat, 27 Jan 2024 23:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706426988; x=1707031788; 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=Y2QCmxBhJ8iqjNBtmsA3jH4k3PqWyOuycGMU2FJ9Brc=; b=B/AVpZ6a9AOReem3j8pljtH1QTlGBl7dcpbK7k1QFEXBRWp7aj9l0pRjWrC0WGXJMK MW7a+B8gq4WAhWBjmu/XekvrbBX/mrZJtMOSSmq529Lq+J6+15hMmy+b2e8i2my0qs6f CZ8yu+QZUuO8a9yEoIVVCZTR/LCyOb3IIJoVsrY20VdHM2s12nmWA90WZcJRi4j3ZvFq 24dilxdHhKtRXWonF5Lc+eEUGt766LwghLPmkvptS/c0BVHdr/X4XFw6ZcE96J9dRfEw K06nCKq2pzXAkcZSLgUuQNlh/Z4D3WZPJ/yF+K6qu0qFa/q58a5xsREMDNBycHMQm71v 5pNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706426988; x=1707031788; 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=Y2QCmxBhJ8iqjNBtmsA3jH4k3PqWyOuycGMU2FJ9Brc=; b=FMO6ZR+W7b7hWgdumSP3qXrpvcVzYuZt89b2RRPWpYH/zx0R4Iwh4smXiAiaRvsYGa e3PcGJtIp/T+5afNHa5ul6wWTwpacTO4dqy62Ma9VzUc3NKPTH5UhtHZqFIrhpKVV3SK WRgvBTQPtANOSIgWj4irxOL5r4rOy+eoPVlPNrrdXDE5xduFOp8hVdrr2iaDY0Kx0RLh aNsbB7v7uyttrI2gyqXPkfkJQWshzTvRNoeLPj9tRbJ1bdr/JIdI/Ym72dIYn/qhsJ7H iDf3tXNe1EiIFz4VVCXku5h7euEWmcYsEllVqLqaBo0rfeVmrCFn1NlJSbkct911iTn7 W3vQ== X-Gm-Message-State: AOJu0Yy74Dxm9maH6vYFLqKHJbeLg6tv0C6PiG/JbhK44y5Kl4KrC2li +7rK0Zj3uUE6du8BGi++GhFBdOhATykn692/CvU+kDSj0bMYj7N+ X-Google-Smtp-Source: AGHT+IGmlbDdqY71Yi4nG4VXN/o4a8MqxT85+kEQ2opCjheBVODOjZD/+DG6IWyNV9+taF2fw2pJ8Q== X-Received: by 2002:a17:90b:1009:b0:28f:ee89:8149 with SMTP id gm9-20020a17090b100900b0028fee898149mr1618904pjb.79.1706426987961; Sat, 27 Jan 2024 23:29:47 -0800 (PST) Received: from smtpclient.apple (172-117-161-177.res.spectrum.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id sl13-20020a17090b2e0d00b00290f9e8b4f9sm3861035pjb.46.2024.01.27.23.29.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jan 2024 23:29:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: bug#68664: 29.1.50; treesit defun commands broken with nested functions From: Yuan Fu In-Reply-To: <86r0i254p9.fsf@gnu.org> Date: Sat, 27 Jan 2024 23:29:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> <86a5or9qpq.fsf@gnu.org> <86r0i254p9.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3731.700.6) X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 68664 Cc: 68664@debbugs.gnu.org, Troy Brown , mardani29@yahoo.es X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Jan 27, 2024, at 10:53 PM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Sat, 27 Jan 2024 20:03:30 -0800 >> Cc: Troy Brown , >> 68664@debbugs.gnu.org, >> mardani29@yahoo.es >>=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.? >>=20 >> 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 >>>=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? >>=20 >> Same for mark-defun, it also has an interactive arg already. >>=20 >> I feel like I missed something, surely you know they already have = interactive args :-) >=20 > "C-u" and "C-u 4" are not the same, and can be distinguished by the > function's body, right? Ah, you=E2=80=99re right. I didn=E2=80=99t know that. If I use = (interactive "P=E2=80=9D), C-u gives my '(4) and C-u 4 give me 4. = That=E2=80=99s what you mean right? In that case, yeah I think it could be useful for C-u mark-defun to mark = the encoding parent rather than next sibling, and C-u beginning-of-defun = to go straight to beg of parent. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 28 02:43:57 2024 Received: (at 68664) by debbugs.gnu.org; 28 Jan 2024 07:43:57 +0000 Received: from localhost ([127.0.0.1]:56491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTzpd-0006y8-65 for submit@debbugs.gnu.org; Sun, 28 Jan 2024 02:43:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rTzpb-0006xs-6f for 68664@debbugs.gnu.org; Sun, 28 Jan 2024 02:43:56 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTzpN-0000DE-Nd; Sun, 28 Jan 2024 02:43:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=aczJyIKy/UjgagkAFWf+iS21MyZO51Hf0LAps0qzx0I=; b=DxfdBp18f4K3bAODYuvH w6I1qXQ+kTR3HbwBDnVPSVWiemckffy1q3KGE8ZTGdd2Vv4+f6quTyBYCThUvyy16FVs1FU+0uGRV eE7pCDxI5JX3RwRJZz0f+pWyH4OJbOHh27D0ooyHOAgZJG4OTnTFm6Ji/E18TPD3S2vrMmNWcvIUa VHAnByrY2rrG7UexmilvVKcOXO5tOqJjurpwD4DxxOX+Xzgk6+dxKF+tLY/vzIBRAK5+7rw5n9OJc pbAL52MFza3v4LI9S2bU6kOxFsnvW5bvUuZBCnDLv8BchqxxlmgfkhF7/7CiYNnUA/wPPzHNrhh5f w6jy2YkFsXibAA==; Date: Sun, 28 Jan 2024 09:43:40 +0200 Message-Id: <86h6ix6gyb.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: (message from Yuan Fu on Sat, 27 Jan 2024 23:29:36 -0800) Subject: Re: bug#68664: 29.1.50; treesit defun commands broken with nested functions References: <42732D94-583F-4F4A-804E-76EFAE91B210@gmail.com> <86a5or9qpq.fsf@gnu.org> <86r0i254p9.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68664 Cc: 68664@debbugs.gnu.org, brownts@troybrown.dev, mardani29@yahoo.es X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Yuan Fu > Date: Sat, 27 Jan 2024 23:29:36 -0800 > Cc: Troy Brown , > 68664@debbugs.gnu.org, > mardani29@yahoo.es > > >> I feel like I missed something, surely you know they already have interactive args :-) > > > > "C-u" and "C-u 4" are not the same, and can be distinguished by the > > function's body, right? > > Ah, you’re right. I didn’t know that. If I use (interactive "P”), C-u gives my '(4) and C-u 4 give me 4. That’s what you mean right? Yes. > In that case, yeah I think it could be useful for C-u mark-defun to mark the encoding parent rather than next sibling, and C-u beginning-of-defun to go straight to beg of parent.