From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 03 13:13:21 2023 Received: (at submit) by debbugs.gnu.org; 3 Jul 2023 17:13:21 +0000 Received: from localhost ([127.0.0.1]:34397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGN73-0007eF-7X for submit@debbugs.gnu.org; Mon, 03 Jul 2023 13:13:21 -0400 Received: from lists.gnu.org ([209.51.188.17]:38256) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGN6x-0007e1-LA for submit@debbugs.gnu.org; Mon, 03 Jul 2023 13:13:19 -0400 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 1qGN6t-0008Th-VG for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 13:13:12 -0400 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 1qGN6t-0008Pr-5M for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 13:13:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Subject:To:From:Date:mime-version:in-reply-to: references; bh=1RTINi50FBgpNULgeBwHobiCtGsDwm3iiLjGVW4r44I=; b=gPtc2nyNeM5gt8 ViTd+oDD0t0ArOkFPKlE9qAWHMzLIhczQ6M/gYMUWOozd/NTuxlsMU9e83cgzRfMz1EXwNJgeAO+B mixj+ERQyxTmjlNjKropS5kjnGnpNnQPU/r9Cb9wM/bqy9XAVRDHVkIe4OMYEdAkKeD5FvM/sy0Gc td1K8scmEycOZg9uyWa99kt7Zh4iRewQZmmzRAd3UnhL503072wAEAn9xz/+SlBeMwruvub1d0jwH voDlGu7D/OIPHEzs/Ey9OI5fL8aP+JSc1Dqn9uHzjHNtCEQVJMYZp5uej8IfseDm1Cjx6GvKNaJh7 nmNgfCMeimEm4bLpU/TQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGN6r-0005bP-Ju for bug-gnu-emacs@gnu.org; Mon, 03 Jul 2023 13:13:10 -0400 Date: Mon, 03 Jul 2023 20:13:47 +0300 Message-Id: <83a5wcncj8.fsf@gnu.org> From: Eli Zaretskii To: bug-gnu-emacs@gnu.org Subject: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C X-Spam-Score: -2.3 (--) 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: -3.3 (---) To reproduce: emacs -Q C-x C-f src/dispnew.c RET M-x c-ts-mode RET C-u 220 M-g g C-M-a Observe that instead of going to the beginning of dump-redisplay-history, the function to which line 220 of dispnew.c belongs, point goes to the beginning of the previous function, which happens to be add_frame_display_history. Can we please fix treesit-beginning-of-defun such that it recognizes C functions defined via DEFUN? In GNU Emacs 29.0.92 (build 20, i686-pc-mingw32) of 2023-07-02 built on HOME-C4E4A596F7 Repository revision: 15ff87617772c2a2c3d8a3a1e2ed7f96e527ad9e Repository branch: emacs-29 Windowing system distributor 'Microsoft Corp.', version 5.1.2600 System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600) Configured using: 'configure -C --prefix=/d/usr --with-wide-int --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: C/* Minor modes in effect: bug-reference-prog-mode: t tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils misearch multi-isearch c-ts-mode c-ts-common treesit cl-seq vc-git diff-mode easy-mmode vc vc-dispatcher bug-reference byte-opt gv bytecomp byte-compile cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 81182 12528) (symbols 48 9662 0) (strings 16 28732 3398) (string-bytes 1 924785) (vectors 16 15907) (vector-slots 8 209599 17044) (floats 8 29 78) (intervals 40 1068 136) (buffers 888 11)) From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 04:41:47 2023 Received: (at 64442) by debbugs.gnu.org; 4 Jul 2023 08:41:47 +0000 Received: from localhost ([127.0.0.1]:34997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGbbX-0001nK-6E for submit@debbugs.gnu.org; Tue, 04 Jul 2023 04:41:47 -0400 Received: from mail-pf1-f170.google.com ([209.85.210.170]:58387) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGbbS-0001n1-3p for 64442@debbugs.gnu.org; Tue, 04 Jul 2023 04:41:45 -0400 Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-668704a5b5bso4100688b3a.0 for <64442@debbugs.gnu.org>; Tue, 04 Jul 2023 01:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688460096; x=1691052096; 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=dA5hh/Qn/H6AsS924MDXD9EQqAR8/e4vvhelI2e0feY=; b=PF/tJhQGNYGVVJIKdRBYQ3pGZaILBBlYUVBwsu/g4xjAobjfAfeB924pERGv4S1CCV i5WCNvdPG+PsGyMGOL7gVax1kdb7/4Gfi1qu9ykC4Jy2hmW/vx4VyTsdgILQD/AwCQUI yz3FwDHzbkxBkGAhirv9sSeJIH7AOuAc5hRPFDYdD+8fQCidmpkDYURAz7iPYzx71u4b SZ9FOM2Htaj44vUHSDAb13Yq//lZEUQf7SfHa3Mhl/ZuKL6Th4XHwVLNh9DsdE+B5am+ wMua9/5vgsEXIZoRUWtV8kkZzkqHzn+kaUNRjY54hM9PpIY3ptx+4PsnhAvnmWQPY5m2 +8+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688460096; x=1691052096; 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=dA5hh/Qn/H6AsS924MDXD9EQqAR8/e4vvhelI2e0feY=; b=UJDnoUKYO6vvpyatQHISJrtpO1ja7zdxFEwGFi9Xz5RcGZgweOWLePW6vSxjvneCim OXW0hV7aHiX9jw64k2duZ89p9HcpzRDUwA/1UTNvBDlYfGj7/q9WS00JL/K9ylwHsFpk pcNeSsYJRArR5pDBH8+WD2N+BnvVg2unBhe1QdnBGwf2o2Q/C4SuG8JTtAS3LX7lcXtM pMyeZ8K14IykfYA+GrVgzB3KAbCgJcrx9rg2VVcEelSNYQmKgw98KYq/nfq1tA+ncWz2 K9aVNAaooIqPELey6actWzR2j3YYpGC19rMEoujYpw1F/r5U4Qrr5b2uF3ADuttx0evH SHUA== X-Gm-Message-State: AC+VfDxuhyPb7I0Ua9jWhD+wiEXSC0JK8BKLM8J184T+UFfbbG4Ch1/z i8A81U2qcztx6BjNIXYEXB/1B7zfUZQ= X-Google-Smtp-Source: ACHHUZ55luJV07ieiQ9b330vCzJfPCqLeWdmNZbxvaV5ag2yz1Hq11YZShRCKXRxltOOqD6aHVJ94A== X-Received: by 2002:a05:6a20:6a0c:b0:127:6bda:a2ae with SMTP id p12-20020a056a206a0c00b001276bdaa2aemr17165011pzk.10.1688460095677; Tue, 04 Jul 2023 01:41:35 -0700 (PDT) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id c184-20020a621cc1000000b0066875f17266sm5706210pfc.135.2023.07.04.01.41.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2023 01:41:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C From: Yuan Fu In-Reply-To: <83a5wcncj8.fsf@gnu.org> Date: Tue, 4 Jul 2023 01:41:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83a5wcncj8.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3731.600.7) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64442 Cc: 64442@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: -1.0 (-) > On Jul 3, 2023, at 10:13 AM, Eli Zaretskii wrote: >=20 > To reproduce: >=20 > emacs -Q > C-x C-f src/dispnew.c RET > M-x c-ts-mode RET > C-u 220 M-g g > C-M-a >=20 > Observe that instead of going to the beginning of > dump-redisplay-history, the function to which line 220 of dispnew.c > belongs, point goes to the beginning of the previous function, which > happens to be add_frame_display_history. >=20 > Can we please fix treesit-beginning-of-defun such that it recognizes C > functions defined via DEFUN? I=E2=80=99ve tried it when I was fixing fontification for DEFUN, but = ultimately gave up. The tree-sitter defun movement functions searches = for defun nodes bottom-up, and goes to the beginning or end of that = node.=20 The problem with DEFUN=E2=80=99s is that a DEFUN is really made of two = nodes in the parse tree. One for the DEFUN part, one for the body, and = there isn=E2=80=99t a parent node that encloses the two.=20 The defun movement functions are not designed to handle a construct made = of two adjacent nodes. They can find a node, go to the beginning/end of = it; they can=E2=80=99t find a node, and go to the end of the next node. It sounds easy to add some hack to handle it, but really isn=E2=80=99t. = Defun movement need to support forward/backward to beg/end, that=E2=80=99s= four movement types; on top of that you have nested defun=E2=80=99s. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 07:39:29 2023 Received: (at 64442) by debbugs.gnu.org; 4 Jul 2023 11:39:29 +0000 Received: from localhost ([127.0.0.1]:35106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGeNU-0000qH-Po for submit@debbugs.gnu.org; Tue, 04 Jul 2023 07:39:29 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGeNQ-0000q2-1O for 64442@debbugs.gnu.org; Tue, 04 Jul 2023 07:39:28 -0400 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 1qGeNK-0005UL-KO; Tue, 04 Jul 2023 07:39:18 -0400 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=1BqtfIKUcdhfaS8bbLIMbLSo9F53Etq2rdLCdGrSCAE=; b=gKwj4oyfqvOHVGHK5+Xi 0rTZJVCBAWwUtecbWn8vRrMZmRejNDKqZ5nQ9LJhtMqflHysY4YYZLjMUgGO8qYsxF8mobfQCwSpa f5s8nKFnM+eCb0mZhtPAS0mV8cRp4eQ8dtsz2LMuryk7iYM4o2BQ5y+pdtE84F9ZXlQJSunaAcy+n P1NUgQF3unpDXEX3LL7WKM31x8D/HI5u+Ih0T3m3gm0EuPfLRbZ1yRhpfj59OYz0yrqSTC9IL8xX3 BA+QrKPB/Y6aZZ677bq94iokGvofso5MdQW79pv6MPjEKmtRa9anE4bJd0h1ZXXU7f0WkqU5G4zZC FrFy2RyQf4HC2A==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGeNJ-0001wO-NF; Tue, 04 Jul 2023 07:39:18 -0400 Date: Tue, 04 Jul 2023 14:39:55 +0300 Message-Id: <83pm57lxbo.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: (message from Yuan Fu on Tue, 4 Jul 2023 01:41:22 -0700) Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C References: <83a5wcncj8.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: 64442 Cc: 64442@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: -3.3 (---) > From: Yuan Fu > Date: Tue, 4 Jul 2023 01:41:22 -0700 > Cc: 64442@debbugs.gnu.org > > The problem with DEFUN’s is that a DEFUN is really made of two nodes in the parse tree. One for the DEFUN part, one for the body, and there isn’t a parent node that encloses the two. > > The defun movement functions are not designed to handle a construct made of two adjacent nodes. They can find a node, go to the beginning/end of it; they can’t find a node, and go to the end of the next node. > > It sounds easy to add some hack to handle it, but really isn’t. Defun movement need to support forward/backward to beg/end, that’s four movement types; Why cannot we look for a top-level expression_statement node which is a call_expression whose function identifier is "DEFUN" and whose position is between the place where C-M-a was invoked and the place where it does find a defun? > on top of that you have nested defun’s. DEFUN's cannot be nested, so we don't need to consider that. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 07 02:15:21 2023 Received: (at 64442) by debbugs.gnu.org; 7 Jul 2023 06:15:21 +0000 Received: from localhost ([127.0.0.1]:42428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHekS-0007My-Ud for submit@debbugs.gnu.org; Fri, 07 Jul 2023 02:15:21 -0400 Received: from mail-pg1-f178.google.com ([209.85.215.178]:47199) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHekQ-0007Mh-57 for 64442@debbugs.gnu.org; Fri, 07 Jul 2023 02:15:19 -0400 Received: by mail-pg1-f178.google.com with SMTP id 41be03b00d2f7-53482b44007so889507a12.2 for <64442@debbugs.gnu.org>; Thu, 06 Jul 2023 23:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688710512; x=1691302512; 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=08RYeE6/ufI6QAHdu22FvGda11GYAk4LSuZnOFnsGCM=; b=iZMIDd2PB4le4XPDyr9Cgj8Kyi1l4fnaqXBRy3wJx8G4gtMx5ih8K/GVoepZO28+cz xRkZJdWVwFggwxVK4erW/OqC4jrlX3swVh3bJKbxmCIMueh0SOBTBe6NjmUgbYg4DhHF Ewy4ibvp7ncPP3gVihkB9nBNk5eqppGR0NenMgqG0i0aRqRPq6OdDPlek59ZZkb5ZvWs iMX4MG4z54xLvvGsaKKIHWLYEnoEmNXMsPaNIIx2OBxYhncn0WldSBK5oEPU+x49i97S ukfZ/9emK+s4jva9aJUUnXAiShBIHY2ZKdYTtJtrbgv+zz9BG+Lu21MUbdmDrAH1DHVx 9Zrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688710512; x=1691302512; 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=08RYeE6/ufI6QAHdu22FvGda11GYAk4LSuZnOFnsGCM=; b=FRj7mzcj398uC28nPpQLummb0LUmePuAS0pBNwB0RAfWBYc6HTo2/HifP/izS6y73C 67qPwkA0OWsyJyZUisR8QaKOxqrJBh8uQMBF6wiEPCHJfDQBCu4eG15W08mjNS4r5ZAB gtJm1rWSXRR8pF+KZsqtiOtqY71Zs6yiZRKyRS5WCmeMLVgx+mY+aa53C8gfiJD3zcHq 5aobaCKcocjnipdemcOS8vzRiLnKqIbsYTW+aMF5oEXvWsaIxS2r4qtyb9E4dLhee46c ymzkDIJpbWSuBDgPqZok7jetsSaj/Z/pnD8HTCm7Lx941kdSlwGDpIo8w4MWv2WTxlH8 73uw== X-Gm-Message-State: ABy/qLa7A3cD6pYreOQIID+fhig68Gq+lVqVN+aqtJDHrXIEezEqVr0f uK0bve7FnFSb0gvvh428nELopMpN/BM= X-Google-Smtp-Source: APBJJlGOsQexFtcNowI79bzKCVhsHVAySoPrI16UqCzV1G9FSCCu5KQELocwBAjKckaVT3BLYNMKow== X-Received: by 2002:a05:6a20:605:b0:12d:1d8f:6af8 with SMTP id 5-20020a056a20060500b0012d1d8f6af8mr2916040pzl.18.1688710512036; Thu, 06 Jul 2023 23:15:12 -0700 (PDT) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id j21-20020a170902c3d500b001993a1fce7bsm2368520plj.196.2023.07.06.23.15.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2023 23:15:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C From: Yuan Fu In-Reply-To: <83pm57lxbo.fsf@gnu.org> Date: Thu, 6 Jul 2023 23:15:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83a5wcncj8.fsf@gnu.org> <83pm57lxbo.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3731.600.7) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64442 Cc: 64442@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: -1.0 (-) > On Jul 4, 2023, at 4:39 AM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Tue, 4 Jul 2023 01:41:22 -0700 >> Cc: 64442@debbugs.gnu.org >>=20 >> The problem with DEFUN=E2=80=99s is that a DEFUN is really made of = two nodes in the parse tree. One for the DEFUN part, one for the body, = and there isn=E2=80=99t a parent node that encloses the two.=20 >>=20 >> The defun movement functions are not designed to handle a construct = made of two adjacent nodes. They can find a node, go to the = beginning/end of it; they can=E2=80=99t find a node, and go to the end = of the next node. >>=20 >> It sounds easy to add some hack to handle it, but really isn=E2=80=99t.= Defun movement need to support forward/backward to beg/end, that=E2=80=99= s four movement types; >=20 > Why cannot we look for a top-level expression_statement node which is > a call_expression whose function identifier is "DEFUN" and whose > position is between the place where C-M-a was invoked and the place > where it does find a defun? It=E2=80=99s gonna be ugly, but I can take a jab at it this weekend. = I=E2=80=99m thinking of a wrapper function that tries to detect DEFUN = before falling back to the ordinary tree-sitter defun movement function. >=20 >> on top of that you have nested defun=E2=80=99s. >=20 > DEFUN's cannot be nested, so we don't need to consider that. Yeah, in general C sources don=E2=80=99t have nested defuns, only C++ = ones do. I was trying to illustrate that it=E2=80=99s hard to extend = existing defun movement framework such that it handles this special = case. The best solution I can think of is what I described above. Yuan= From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 07 02:40:20 2023 Received: (at 64442) by debbugs.gnu.org; 7 Jul 2023 06:40:21 +0000 Received: from localhost ([127.0.0.1]:42450 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHf8e-00081w-G4 for submit@debbugs.gnu.org; Fri, 07 Jul 2023 02:40:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38130) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHf8a-00081h-3K for 64442@debbugs.gnu.org; Fri, 07 Jul 2023 02:40:19 -0400 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 1qHf8U-0006RR-Qq; Fri, 07 Jul 2023 02:40:10 -0400 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=S0xM3Xy4oaBbPg8HZNfX8I7RovB1GaMYmi0HLSwHosc=; b=DEjSuPfensxr5ssP0RTY TZd+VCENGjpwFGM/sVS2xdy6PepfqicaatZ7EHc63bx38gvjuE97kF0K7Q3eNcVTq4UaQSk6i6tjf LNcsT0CaejEgg2PJQ1aPlIGD1fo4b4vnxtuuHDEIFF4k59Zn4w4ATu2HFU+HQDHNudrpeDA0XPz7u o7weJbj+EGhNhVSDyMvSTHiATuLANpbzk6lpWgw42XgCjVD5sja4xcHzy92TB5v958iicKDETyZkL btj7eQbc0LmyZ9luPYEeOr8dY/qJhGpws2PnB81XUn5LwCojDPVg0LeJsqFHzXuxoFaHqPOH8Ml7g Wn1l1vg+9yyBCg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHf8T-0005zP-Sc; Fri, 07 Jul 2023 02:40:10 -0400 Date: Fri, 07 Jul 2023 09:40:12 +0300 Message-Id: <835y6wgr77.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: (message from Yuan Fu on Thu, 6 Jul 2023 23:15:00 -0700) Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C References: <83a5wcncj8.fsf@gnu.org> <83pm57lxbo.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: 64442 Cc: 64442@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: -3.3 (---) > From: Yuan Fu > Date: Thu, 6 Jul 2023 23:15:00 -0700 > Cc: 64442@debbugs.gnu.org > > > On Jul 4, 2023, at 4:39 AM, Eli Zaretskii wrote: > > > > Why cannot we look for a top-level expression_statement node which is > > a call_expression whose function identifier is "DEFUN" and whose > > position is between the place where C-M-a was invoked and the place > > where it does find a defun? > > It’s gonna be ugly, but I can take a jab at it this weekend. I’m thinking of a wrapper function that tries to detect DEFUN before falling back to the ordinary tree-sitter defun movement function. Thanks. let's see how ugly it is before deciding whether it's worth it. > > DEFUN's cannot be nested, so we don't need to consider that. > > Yeah, in general C sources don’t have nested defuns, only C++ ones do. No, I meant the use of DEFUN macros in Emacs cannot be nested. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 11 22:10:22 2023 Received: (at 64442) by debbugs.gnu.org; 12 Jul 2023 02:10:22 +0000 Received: from localhost ([127.0.0.1]:51259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJPJ8-0004wA-8j for submit@debbugs.gnu.org; Tue, 11 Jul 2023 22:10:22 -0400 Received: from mail-ot1-f53.google.com ([209.85.210.53]:52421) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJPJ4-0004vq-NY for 64442@debbugs.gnu.org; Tue, 11 Jul 2023 22:10:21 -0400 Received: by mail-ot1-f53.google.com with SMTP id 46e09a7af769-6b8decf09e1so5670310a34.0 for <64442@debbugs.gnu.org>; Tue, 11 Jul 2023 19:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689127813; x=1691719813; 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=bC72Xk1kZW7SwMtM8DpHbqEY2inHv2/Q05RIihaJoMA=; b=gEjmtdinUVr2o9ufZ66DpvL2eT/dF53YbPmcmrgMe9SiAYCJt7AC2XLYtW3YCkvle4 gUTyLfwOeRwCG/ct0Glbt515Sr8+rWEsnrpu6CpggVZ1MPKbZySIyMlRKCpEll4J6MSr fBsg4bj0sDYfQXJ5Ys9K4Ognyg7lfnLNI2bXSQ4RJDUDKrpTSBGAmaE7pVpSku0GYtaO jC1oxY12OlVADYp6G2gAgGljb7P8O9YiRWgM3jkx5trbKC6irEPruZozfDN/WzEiCFxT 2abUBkNEFKz2h6Dm5qWpEvy0BvlsxnehJwoDI+9B1/xOY4doUfj9tLhfpOoUpAhdF11q wFKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689127813; x=1691719813; 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=bC72Xk1kZW7SwMtM8DpHbqEY2inHv2/Q05RIihaJoMA=; b=LSxw1LemURJymqF2aJqzF/yyxJ/qU1DJ21FRSb7es6+NQ2bf2+WKrqguBBOD4TJWGb mDHdtojBGtR5H0EzegRFGar1GKhSGIOKYyz7bVKEI6tkC6t+Z+Xef04La2nCLT2G/t5g h0XvhAXN4MJFWxrdXqy4fNxACkcWV/6CSszFH35jkIjJ2YZkSPxLisN+fMnqunuc9FJp BfvPeP7+iVQNDE1UUQwvBTLYTyhxzGeCwEE737acWc/Yms8H/iw0xSQxOBDUcvoL9wM3 e/QdUZUwvOOIUcOvpTtRuFJKAGLJ04S3s1aibWEiCrZL5ZxA9qVxWXwwNcHKsaeF38lb ZcbA== X-Gm-Message-State: ABy/qLZ16X+XBwp2caEpHvdK0FVdxsfHxz96IpwUbbvn/tJxPJz6on9c bhUmxFAl830JcjWkbETr6N2d9M0LIlg= X-Google-Smtp-Source: APBJJlHVsNesBGicQW1AOhGzzDjJPWNW5QMtWsuam8d1GilS1gH3nRho/oPEvU0IUnWnYFJTdCTPbg== X-Received: by 2002:a05:6830:11cb:b0:6b9:5810:84d2 with SMTP id v11-20020a05683011cb00b006b9581084d2mr3934556otq.6.1689127812782; Tue, 11 Jul 2023 19:10:12 -0700 (PDT) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id w4-20020a17090a6b8400b00263fd82106asm2662821pjj.35.2023.07.11.19.10.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2023 19:10:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C From: Yuan Fu In-Reply-To: <835y6wgr77.fsf@gnu.org> Date: Tue, 11 Jul 2023 19:10:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <93E5B9EA-D349-4316-B314-D6994329C261@gmail.com> References: <83a5wcncj8.fsf@gnu.org> <83pm57lxbo.fsf@gnu.org> <835y6wgr77.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3731.600.7) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64442 Cc: 64442@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: -1.0 (-) > On Jul 6, 2023, at 11:40 PM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Thu, 6 Jul 2023 23:15:00 -0700 >> Cc: 64442@debbugs.gnu.org >>=20 >>> On Jul 4, 2023, at 4:39 AM, Eli Zaretskii wrote: >>>=20 >>> Why cannot we look for a top-level expression_statement node which = is >>> a call_expression whose function identifier is "DEFUN" and whose >>> position is between the place where C-M-a was invoked and the place >>> where it does find a defun? >>=20 >> It=E2=80=99s gonna be ugly, but I can take a jab at it this weekend. = I=E2=80=99m thinking of a wrapper function that tries to detect DEFUN = before falling back to the ordinary tree-sitter defun movement function. >=20 > Thanks. let's see how ugly it is before deciding whether it's worth = it. >=20 >>> DEFUN's cannot be nested, so we don't need to consider that. >>=20 >> Yeah, in general C sources don=E2=80=99t have nested defuns, only C++ = ones do. >=20 > No, I meant the use of DEFUN macros in Emacs cannot be nested. Just an update. I didn=E2=80=99t forget about this, but it=E2=80=99s = more harder than I thought and I=E2=80=99m still working on it :-( Yuan= From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 30 03:10:45 2023 Received: (at 64442) by debbugs.gnu.org; 30 Jul 2023 07:10:45 +0000 Received: from localhost ([127.0.0.1]:49257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qQ0Zg-0000WM-Tj for submit@debbugs.gnu.org; Sun, 30 Jul 2023 03:10:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qQ0Ze-0000W9-3I for 64442@debbugs.gnu.org; Sun, 30 Jul 2023 03:10:43 -0400 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 1qQ0ZY-0001Py-Iy; Sun, 30 Jul 2023 03:10:36 -0400 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=pWx9fk0cWf9X5Mz2LavgXzIcl6r2VMIZ5+GMAoV2KS4=; b=oFllIOYOJFeFHqxiv+aV kg/3G8o1XFy/KrpxqVwxkcn890bOAxJ3nzocwMmP74dOwtHyXpZeC9ibqgekmJjd7Oouv6z7hWqZi z2qWP9DKL41yc7eQF2EYoA7R4qEDiucj/sBpykLWCIFvSxA4GMdI1g1/82niT8Dd6uqpijbjcibCF UZCcr/qESPW3zOyyZWOO/rIpMypa8sj98Kkfo9y4yqgKx5MjQY+AoP00LgLuPeRXt6Fa6w7KpAyhf Ano+/4RG2hfp9N55fpgY8nG3BRfrlX0zM0Qg3cu44B7qrXEoCIobY2XqczNMbqdXl6jrIv3q6reck 7MAypTkZ7+O+ZQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qQ0ZX-0002Gj-RQ; Sun, 30 Jul 2023 03:10:36 -0400 Date: Sun, 30 Jul 2023 10:10:35 +0300 Message-Id: <83r0oplvro.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: <93E5B9EA-D349-4316-B314-D6994329C261@gmail.com> (message from Yuan Fu on Tue, 11 Jul 2023 19:10:01 -0700) Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C References: <83a5wcncj8.fsf@gnu.org> <83pm57lxbo.fsf@gnu.org> <835y6wgr77.fsf@gnu.org> <93E5B9EA-D349-4316-B314-D6994329C261@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: 64442 Cc: 64442@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: -3.3 (---) > From: Yuan Fu > Date: Tue, 11 Jul 2023 19:10:01 -0700 > Cc: 64442@debbugs.gnu.org > > > > > On Jul 6, 2023, at 11:40 PM, Eli Zaretskii wrote: > > > >> From: Yuan Fu > >> Date: Thu, 6 Jul 2023 23:15:00 -0700 > >> Cc: 64442@debbugs.gnu.org > >> > >>> On Jul 4, 2023, at 4:39 AM, Eli Zaretskii wrote: > >>> > >>> Why cannot we look for a top-level expression_statement node which is > >>> a call_expression whose function identifier is "DEFUN" and whose > >>> position is between the place where C-M-a was invoked and the place > >>> where it does find a defun? > >> > >> It’s gonna be ugly, but I can take a jab at it this weekend. I’m thinking of a wrapper function that tries to detect DEFUN before falling back to the ordinary tree-sitter defun movement function. > > > > Thanks. let's see how ugly it is before deciding whether it's worth it. > > > >>> DEFUN's cannot be nested, so we don't need to consider that. > >> > >> Yeah, in general C sources don’t have nested defuns, only C++ ones do. > > > > No, I meant the use of DEFUN macros in Emacs cannot be nested. > > Just an update. I didn’t forget about this, but it’s more harder than I thought and I’m still working on it :-( Any progress with this? It would be good to have a solution in Emacs 29.2, if possible. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 10 05:18:33 2023 Received: (at 64442) by debbugs.gnu.org; 10 Aug 2023 09:18:33 +0000 Received: from localhost ([127.0.0.1]:41388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU1oP-0006G9-CF for submit@debbugs.gnu.org; Thu, 10 Aug 2023 05:18:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36378) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU1oN-0006Fv-Dt for 64442@debbugs.gnu.org; Thu, 10 Aug 2023 05:18:32 -0400 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 1qU1oI-0000Qx-6D; Thu, 10 Aug 2023 05:18:26 -0400 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=AUTJK0Chnv5hmz6zotyOdjk8H2F8C+rkJnQMQgTUJtc=; b=dHqT7Kmo8+yq0xVaXNI2 7BQkn40Wb4WA3ZSkhPTFzv5yOAfXpXeAZb+8rDtxDCv+VwamJp2AFBkKO2AGVob/rrl5h4/gy7ISK R8si0Wxr6c6R+d06oSWSR+ZS7VDEPMpweJkrJIkyqZrBKfmMUQVBqpGZ1RIwXrAJxB/nWi0rgS5k8 U80UZW7MLyyIKR24J2ac40haeOt7pwFxt0GEjduRAAL63tkcXLi0Enh4ViHDj5iZAC44IiD/BCR4E SotJQ2O5RV8lotHi9H+0IV6tSMQIuPuhDIAk8o6203hMu5X0v+dr7+dg9X4ohvUjWfDVLusm/czWw CywkFjhNZ3/c0A==; Date: Thu, 10 Aug 2023 12:18:52 +0300 Message-Id: <83y1iji7b7.fsf@gnu.org> From: Eli Zaretskii To: casouri@gmail.com In-Reply-To: <83r0oplvro.fsf@gnu.org> (message from Eli Zaretskii on Sun, 30 Jul 2023 10:10:35 +0300) Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C References: <83a5wcncj8.fsf@gnu.org> <83pm57lxbo.fsf@gnu.org> <835y6wgr77.fsf@gnu.org> <93E5B9EA-D349-4316-B314-D6994329C261@gmail.com> <83r0oplvro.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: 64442 Cc: 64442@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: -3.3 (---) > Cc: 64442@debbugs.gnu.org > Date: Sun, 30 Jul 2023 10:10:35 +0300 > From: Eli Zaretskii > > > From: Yuan Fu > > Date: Tue, 11 Jul 2023 19:10:01 -0700 > > Cc: 64442@debbugs.gnu.org > > > > > > > > > On Jul 6, 2023, at 11:40 PM, Eli Zaretskii wrote: > > > > > >> From: Yuan Fu > > >> Date: Thu, 6 Jul 2023 23:15:00 -0700 > > >> Cc: 64442@debbugs.gnu.org > > >> > > >>> On Jul 4, 2023, at 4:39 AM, Eli Zaretskii wrote: > > >>> > > >>> Why cannot we look for a top-level expression_statement node which is > > >>> a call_expression whose function identifier is "DEFUN" and whose > > >>> position is between the place where C-M-a was invoked and the place > > >>> where it does find a defun? > > >> > > >> It’s gonna be ugly, but I can take a jab at it this weekend. I’m thinking of a wrapper function that tries to detect DEFUN before falling back to the ordinary tree-sitter defun movement function. > > > > > > Thanks. let's see how ugly it is before deciding whether it's worth it. > > > > > >>> DEFUN's cannot be nested, so we don't need to consider that. > > >> > > >> Yeah, in general C sources don’t have nested defuns, only C++ ones do. > > > > > > No, I meant the use of DEFUN macros in Emacs cannot be nested. > > > > Just an update. I didn’t forget about this, but it’s more harder than I thought and I’m still working on it :-( > > Any progress with this? It would be good to have a solution in Emacs > 29.2, if possible. Ping! From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 10 17:33:32 2023 Received: (at 64442) by debbugs.gnu.org; 10 Aug 2023 21:33:33 +0000 Received: from localhost ([127.0.0.1]:44191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUDHg-0001qq-AK for submit@debbugs.gnu.org; Thu, 10 Aug 2023 17:33:32 -0400 Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]:61728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUDHb-0001qZ-SW for 64442@debbugs.gnu.org; Thu, 10 Aug 2023 17:33:30 -0400 Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-1bbbbb77b38so10388015ad.3 for <64442@debbugs.gnu.org>; Thu, 10 Aug 2023 14:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691703202; x=1692308002; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=ZxH5n7okGPrd3p6wp4PdLsRG5A6Z0wss5nmXmOkYCWU=; b=nQ90x01BgE/dDldFD5qyZMKZnJaXKRcfb/2JiUqelw22liAKuhhAH1F1xRX71V2q+l s+DlKbZb1riamFHj2AjCtBBKIcCkpskKgeiv43kk5UfY81Hmd/+CbXxyvpYg5nB80iOp GaOO7R+svLtVaZjGcKwPWq8l/j9KNpQoZ23/9b21mDfoKkbzW1JmFWGi28u2I4OLRg3o xLS0FbX6ESGR9GBQ9laDVpZvHy56TxnSF1ayKm6TVNnc4He6cNTUJqgP34z3aHY5Yqx4 aoHYpqdOkGtR40w2d9I8SZEsowNFD7JLycMi6BJw+NlgDEZ9dWjbl/ZNPrTkkoGV9jB0 un4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691703202; x=1692308002; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZxH5n7okGPrd3p6wp4PdLsRG5A6Z0wss5nmXmOkYCWU=; b=FXy2FJOH2GaxPowQtHwybcIP+TLKcedfbeXthxWc5KAuZOyx2hBndqTWZZwhsncE3V VtPhqpaGAKXEuZ3jfgmX0I8ZTI6SzFL5FCvjTbdTy4eb9mwKFBVoKMbC5ixJxvfnT6u9 4KbG6+LooR+pAMMl9Tm4Qn3YTWZftFoLjuIEvAHZukwUFi8ZXPTRGYCxx9q6YkstCqIu oZVC+JNY4kDKriKwgeWsrgj9oBUjFSHbt1zaNWyrhIRiZbECatWFDZJbyOQc4UCD7OHf mNBXBarkC5/Kinv5VuOraiHa6pMGtB/jC5Vja+P+Wi4RuywSEAl8j2p8aVzpnc2hm0ee uf5w== X-Gm-Message-State: AOJu0YxHK4TXpyJ26r2Q9R6rRjSkk6zov456HGb8KgATWbXNmST+AnMa 8aVTM9Iwh1nQc5Ci1Q3xTzI= X-Google-Smtp-Source: AGHT+IGAOKTrL13/k1/KCPDmgegV3A9P6fQWnEN/1vlAgaqCCyypQ8hdHhgkj7L/5JKxRYgkCPF4qA== X-Received: by 2002:a17:903:41c5:b0:1b5:64a4:bea0 with SMTP id u5-20020a17090341c500b001b564a4bea0mr29340ple.10.1691703202020; Thu, 10 Aug 2023 14:33:22 -0700 (PDT) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id q3-20020a170902788300b001bbd8cf6b57sm2243673pll.230.2023.08.10.14.33.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2023 14:33:21 -0700 (PDT) From: Yuan Fu Message-Id: <2134730B-05A4-4032-84B6-42FD3CDC48AE@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_FB14F0E2-802C-48A7-9687-BFF139A999CF" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C Date: Thu, 10 Aug 2023 14:33:09 -0700 In-Reply-To: <83y1iji7b7.fsf@gnu.org> To: Eli Zaretskii References: <83a5wcncj8.fsf@gnu.org> <83pm57lxbo.fsf@gnu.org> <835y6wgr77.fsf@gnu.org> <93E5B9EA-D349-4316-B314-D6994329C261@gmail.com> <83r0oplvro.fsf@gnu.org> <83y1iji7b7.fsf@gnu.org> X-Mailer: Apple Mail (2.3731.600.7) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 64442 Cc: 64442@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: -1.0 (-) --Apple-Mail=_FB14F0E2-802C-48A7-9687-BFF139A999CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 10, 2023, at 2:18 AM, Eli Zaretskii wrote: >=20 >> Cc: 64442@debbugs.gnu.org >> Date: Sun, 30 Jul 2023 10:10:35 +0300 >> From: Eli Zaretskii >>=20 >>> From: Yuan Fu >>> Date: Tue, 11 Jul 2023 19:10:01 -0700 >>> Cc: 64442@debbugs.gnu.org >>>=20 >>>=20 >>>=20 >>>> On Jul 6, 2023, at 11:40 PM, Eli Zaretskii wrote: >>>>=20 >>>>> From: Yuan Fu >>>>> Date: Thu, 6 Jul 2023 23:15:00 -0700 >>>>> Cc: 64442@debbugs.gnu.org >>>>>=20 >>>>>> On Jul 4, 2023, at 4:39 AM, Eli Zaretskii wrote: >>>>>>=20 >>>>>> Why cannot we look for a top-level expression_statement node = which is >>>>>> a call_expression whose function identifier is "DEFUN" and whose >>>>>> position is between the place where C-M-a was invoked and the = place >>>>>> where it does find a defun? >>>>>=20 >>>>> It=E2=80=99s gonna be ugly, but I can take a jab at it this = weekend. I=E2=80=99m thinking of a wrapper function that tries to detect = DEFUN before falling back to the ordinary tree-sitter defun movement = function. >>>>=20 >>>> Thanks. let's see how ugly it is before deciding whether it's = worth it. >>>>=20 >>>>>> DEFUN's cannot be nested, so we don't need to consider that. >>>>>=20 >>>>> Yeah, in general C sources don=E2=80=99t have nested defuns, only = C++ ones do. >>>>=20 >>>> No, I meant the use of DEFUN macros in Emacs cannot be nested. >>>=20 >>> Just an update. I didn=E2=80=99t forget about this, but it=E2=80=99s = more harder than I thought and I=E2=80=99m still working on it :-( >>=20 >> Any progress with this? It would be good to have a solution in Emacs >> 29.2, if possible. >=20 > Ping! I still don=E2=80=99t have a good solution. But I just realized that we = might be able to make a little compromise: what if Emacs recognizes = DEFUN, but as two separate parts (the declaration and the body), rather = than one? It=E2=80=99s hard to make it recognize DEFUN as a single = defun, but making it recognize DEFUN as two parts is easy. Try this patch and see if you like the behavior. Personally I find it = quite alright. Yuan --Apple-Mail=_FB14F0E2-802C-48A7-9687-BFF139A999CF Content-Disposition: attachment; filename=defun-nav.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="defun-nav.patch" Content-Transfer-Encoding: quoted-printable =46rom=20b0e361b430650e95449c59b8643be58d598cde58=20Mon=20Sep=2017=20= 00:00:00=202001=0AFrom:=20Yuan=20Fu=20=0ADate:=20Thu,=20= 10=20Aug=202023=2014:27:29=20-0700=0ASubject:=20[PATCH]=20Support=20= defun=20navigation=20for=20DEFUN=20in=20c-ts-mode=20(bug#64442)=0A=0A= Before=20this=20change,=20beginning/end-of-defun=20just=20ignores=20= DEFUN=20in=0Ac-ts-mode.=20After=20this=20change,=20= beginning/end-of-defun=20can=20recognize=0ADEFUN,=20but=20a=20DEFUN=20= definition=20is=20considered=20two=20defuns.=20Eg,=0A= beginning/end-of-defun=20will=20stop=20at=20(1)=20(2)=20and=20(3)=20in=20= the=20following=0Asnippet:=0A=0A(1)DEFUN=20("treesit-node-parser",=0A=20=20= =20=20=20=20=20Ftreesit_node_parser,=20Streesit_node_parser,=0A=20=20=20=20= =20=20=201,=201,=200,=0A=20=20=20=20=20=20=20doc:=20/*=20Return=20the=20= parser=20to=20which=20NODE=20belongs.=20=20*/)=0A=20=20(Lisp_Object=20= node)=0A(2){=0A=20=20CHECK_TS_NODE=20(node);=0A=20=20return=20XTS_NODE=20= (node)->parser;=0A}=0A(3)=0A=0AIdeally=20we=20want=20point=20to=20only=20= stop=20at=20(1)=20and=20(3),=20but=20that'll=20be=20a=0Alot=20harder=20= to=20do.=0A=0A*=20lisp/progmodes/c-ts-mode.el:=0A= (c-ts-mode--defun-valid-p):=20Refactor=20to=20take=20in=20account=20of=20= DEFUN=20body.=0A(c-ts-mode--emacs-defun-body-p):=20New=20function.=0A= (c-ts-base-mode):=20Add=20DEFUN=20and=20DEFUN=20body=20to=20recognized=20= types.=0A---=0A=20lisp/progmodes/c-ts-mode.el=20|=2064=20= +++++++++++++++++++++++--------------=0A=201=20file=20changed,=2040=20= insertions(+),=2024=20deletions(-)=0A=0Adiff=20--git=20= a/lisp/progmodes/c-ts-mode.el=20b/lisp/progmodes/c-ts-mode.el=0Aindex=20= 7f4f6f11387..0eb1f2a17a7=20100644=0A---=20a/lisp/progmodes/c-ts-mode.el=0A= +++=20b/lisp/progmodes/c-ts-mode.el=0A@@=20-882,29=20+882,36=20@@=20= c-ts-mode--defun-name=0A=20(defun=20c-ts-mode--defun-valid-p=20(node)=0A=20= =20=20"Return=20non-nil=20if=20NODE=20is=20a=20valid=20defun=20node.=0A=20= Ie,=20NODE=20is=20not=20nested."=0A-=20=20(or=20= (c-ts-mode--emacs-defun-p=20node)=0A-=20=20=20=20=20=20(not=20(or=20(and=20= (member=20(treesit-node-type=20node)=0A-=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20'("struct_specifier"=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20"enum_specifier"=0A-=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"union_specifier"=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20"declaration"))=0A-=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20;;=20If=20NODE's=20type=20is=20one=20of=20the=20= above,=20make=20sure=20it=20is=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20;;=20top-level.=0A-=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20(treesit-node-top-level=0A-=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20node=20(rx=20(or=20= "function_definition"=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"type_definition"=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20"struct_specifier"=0A-=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20"enum_specifier"=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"union_specifier"=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20"declaration"))))=0A-=0A-=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20(and=20(equal=20(treesit-node-type=20node)=20= "declaration")=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20;;=20If=20NODE=20is=20a=20declaration,=20make=20sure=20it=20is=20not=20= a=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20;;=20= function=20declaration.=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20(equal=20(treesit-node-type=0A-=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= (treesit-node-child-by-field-name=0A-=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20node=20"declarator"))=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20"function_declarator"))))))=0A+=20=20(let=20((top-level-p=20= (lambda=20(node)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20(not=20(treesit-node-top-level=0A+=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20node=20= (rx=20(or=20"function_definition"=0A+=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20"type_definition"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20"struct_specifier"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20"enum_specifier"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20"union_specifier"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20"declaration")))))))=0A+=20=20=20=20(pcase=20(treesit-node-type=20= node)=0A+=20=20=20=20=20=20;;=20The=20declaration=20part=20of=20a=20= DEFUN.=0A+=20=20=20=20=20=20("expression_statement"=20= (c-ts-mode--emacs-defun-p=20node))=0A+=20=20=20=20=20=20;;=20The=20body=20= of=20a=20DEFUN.=0A+=20=20=20=20=20=20("compound_statement"=20= (c-ts-mode--emacs-defun-body-p=20node))=0A+=20=20=20=20=20=20;;=20If=20= NODE's=20type=20is=20one=20of=20these=20three,=20make=20sure=20it=20is=0A= +=20=20=20=20=20=20;;=20top-level.=0A+=20=20=20=20=20=20((or=20= "struct_specifier"=0A+=20=20=20=20=20=20=20=20=20=20=20"enum_specifier"=0A= +=20=20=20=20=20=20=20=20=20=20=20"union_specifier")=0A+=20=20=20=20=20=20= =20(funcall=20top-level-p=20node))=0A+=20=20=20=20=20=20;;=20If=20NODE=20= is=20a=20declaration,=20make=20sure=20it's=20not=20a=20function=0A+=20=20= =20=20=20=20;;=20declaration=20(we=20only=20want=20function_definition)=20= and=20is=20a=0A+=20=20=20=20=20=20;;=20top-level=20declaration.=0A+=20=20= =20=20=20=20("declaration"=0A+=20=20=20=20=20=20=20(and=20(not=20(equal=20= (treesit-node-type=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20(treesit-node-child-by-field-name=0A+=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20node=20= "declarator"))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20"function_declarator"))=0A+=20=20=20=20=20=20=20=20=20=20=20= =20(funcall=20top-level-p=20node)))=0A+=20=20=20=20=20=20;;=20Other=20= types=20don't=20need=20further=20verification.=0A+=20=20=20=20=20=20(_=20= t))))=0A=20=0A=20(defun=20c-ts-mode--defun-for-class-in-imenu-p=20(node)=0A= =20=20=20"Check=20if=20NODE=20is=20a=20valid=20entry=20for=20the=20Class=20= subindex.=0A@@=20-957,6=20+964,11=20@@=20c-ts-mode--emacs-defun-p=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20t)=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20"DEFUN")))=0A=20=0A+(defun=20= c-ts-mode--emacs-defun-body-p=20(node)=0A+=20=20"Return=20non-nil=20if=20= NODE=20is=20the=20function=20body=20of=20a=20DEFUN."=0A+=20=20(and=20= (equal=20(treesit-node-type=20node)=20"compound_statement")=0A+=20=20=20=20= =20=20=20(c-ts-mode--emacs-defun-p=20(treesit-node-prev-sibling=20= node))))=0A+=0A=20(defun=20c-ts-mode--emacs-defun-at-point=20(&optional=20= range)=0A=20=20=20"Return=20the=20defun=20node=20at=20point.=0A=20=0A@@=20= -1119,7=20+1131,11=20@@=20c-ts-base-mode=0A=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= "enum_specifier"=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"union_specifier"=0A=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20"class_specifier"=0A-=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= "namespace_definition"))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= "namespace_definition"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20;;=20DEFUN.=0A+=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20"expression_statement"=0A+=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= ;;=20DEFUN=20body.=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= "compound_statement"))=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20#'c-ts-mode--defun-valid-p))=0A=20=20=20(setq-local=20= treesit-defun-skipper=20#'c-ts-mode--defun-skipper)=0A=20=20=20= (setq-local=20treesit-defun-name-function=20#'c-ts-mode--defun-name)=0A= --=20=0A2.41.0=0A=0A= --Apple-Mail=_FB14F0E2-802C-48A7-9687-BFF139A999CF-- From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 12 10:59:15 2023 Received: (at 64442) by debbugs.gnu.org; 12 Aug 2023 14:59:15 +0000 Received: from localhost ([127.0.0.1]:51002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUq5D-0002Jl-8Z for submit@debbugs.gnu.org; Sat, 12 Aug 2023 10:59:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36322) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUq59-0002JU-8z for 64442@debbugs.gnu.org; Sat, 12 Aug 2023 10:59:14 -0400 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 1qUq53-0004gi-SU; Sat, 12 Aug 2023 10:59:05 -0400 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=2t9fw40Rr+nVYKUmiVLX6x10d77yO+XA065rlB3AryY=; b=FWU8QNAl14IokLWcj1lm 7vq8sAcC7KpRxHLeRoOWAm8bPptVTWBvoIxPxJd/FW1M6TpcLx58vm7cOqD0yAh6UM3azzXVqgEyN BOmIm8ujkWDV8Efdd3UdzBanm1oCXKgaZb3XvFTtUdmYCPpc422SSulkX/WkHqFhfA5mcqIqc2z0Q JzuZehukNLz1KU5m+K2DQAiQ8jNKxWA4N1J1AJ5PZK3acKA1Y61lcNsVEADLMHaNsFfej7sN2/BZR mgQAEOvwhsN0wa014QxI5e8TXzjE4l5bpWFz/mjxixtC7iGkkOPwCMTVy/7tCpzgbsmMSR6quOZk2 Psv9/hyt+qm0Cg==; Date: Sat, 12 Aug 2023 17:59:37 +0300 Message-Id: <83a5uwe27a.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: <2134730B-05A4-4032-84B6-42FD3CDC48AE@gmail.com> (message from Yuan Fu on Thu, 10 Aug 2023 14:33:09 -0700) Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C References: <83a5wcncj8.fsf@gnu.org> <83pm57lxbo.fsf@gnu.org> <835y6wgr77.fsf@gnu.org> <93E5B9EA-D349-4316-B314-D6994329C261@gmail.com> <83r0oplvro.fsf@gnu.org> <83y1iji7b7.fsf@gnu.org> <2134730B-05A4-4032-84B6-42FD3CDC48AE@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: 64442 Cc: 64442@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: -3.3 (---) > From: Yuan Fu > Date: Thu, 10 Aug 2023 14:33:09 -0700 > Cc: 64442@debbugs.gnu.org > > I still don’t have a good solution. But I just realized that we might be able to make a little compromise: what if Emacs recognizes DEFUN, but as two separate parts (the declaration and the body), rather than one? It’s hard to make it recognize DEFUN as a single defun, but making it recognize DEFUN as two parts is easy. > > Try this patch and see if you like the behavior. Personally I find it quite alright. I like this much better than what we have now, thanks. But I have a question: can we perhaps recognize the "function" of the body as such, and then automatically move to the previous defun, which is the right place? The "defun" that is the body has no name, so maybe that could be used as a sign? That would allow "C-x 4 a" to work inside a DEFUN, something that still works less reliably with this patch: you must be in the "first defun" to get it to find the name of the function. But if improving this is hard, I'll settle for what you have now, thanks a lot. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 01:21:16 2023 Received: (at 64442) by debbugs.gnu.org; 14 Aug 2023 05:21:17 +0000 Received: from localhost ([127.0.0.1]:60856 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVQ0y-0004NM-EP for submit@debbugs.gnu.org; Mon, 14 Aug 2023 01:21:16 -0400 Received: from mail-pg1-x536.google.com ([2607:f8b0:4864:20::536]:45067) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVQ0w-0004N7-5x for 64442@debbugs.gnu.org; Mon, 14 Aug 2023 01:21:15 -0400 Received: by mail-pg1-x536.google.com with SMTP id 41be03b00d2f7-565439b6b3fso2219061a12.2 for <64442@debbugs.gnu.org>; Sun, 13 Aug 2023 22:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691990468; x=1692595268; 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=6f8Oe4Kn+tuvD6Mqj4kNj6UrvB/DQj7ot+NPnFMac64=; b=qme+EeLHT+IQioxb0d5LINFcMH7rKpzQAm4F30oe3bZ1MyjcEma50Rnwug8Ca6TSpR 23t1l7qhMrSZmvUy8V+jpwBp7zi/tgwWdyDJZC0GiDp6UZgG5lotl0rzCub1FDaLdf5C vkIkoIqLXqBnThR98r/cl/9kLOlaO5qEEeBgdCtrkENW3b6KYfGzr22lSzsumuKRiNrZ McvKgVm3O0wlM5P00yLYk08H0SoxNBbNIY0m3JJ1PKcqXeudfTPzpebAOFccn6ZFw+UV k4u/gqlxcNv7/m4zTo3pq2PH2sujsiKC2sk9FpQ7yt/xVedoVMMBPDEvvyD+YlnBOYyK XreQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691990468; x=1692595268; 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=6f8Oe4Kn+tuvD6Mqj4kNj6UrvB/DQj7ot+NPnFMac64=; b=RxbEcQJXZCWL+mivP7br8rF/Yrgbfem7TIFT0TQyuTf4w4utUj4hZS96JaxQ3hUgos 2AkC2x630pbTR0bOMLPysJsAaIbEIRcHNhySMPicXE03HCHg7e4CBgyD83aSvhHv0Nfs ycXCHqMsoVXtMSahR9vY5IJVBS1QjvhYVykzhK+eaT6y4bshJ/pOnR+yGgtIumvX7PMi Fn37BJ0LUzUshG8DBIfsS/7wpyVwy8dcOuRzVfABxc+lZRxdNL7NIAJEjHz5vqu7Ylt8 nefn+6avUOeBGYoihjnSHNUVmAgqvFrPrit0fpxmrqw1IRti99x48PbLLAn6NxBl4bkF V8Dw== X-Gm-Message-State: AOJu0YyD03Q2Jq7wHp/XklAb5PUzz07MhkDMS0ARRQ+x+ExuioO/0G4P P6wfJ5JfXd6L9/sm/qEGw4E= X-Google-Smtp-Source: AGHT+IEbmCXtyw9eswrTK5QmwbR0dATQw8CKHDcJbUTjGaKVMrATG4DycG7pFfio4DV4x7dUiEKRjg== X-Received: by 2002:a05:6a21:9994:b0:130:7803:5843 with SMTP id ve20-20020a056a21999400b0013078035843mr10687333pzb.4.1691990468307; Sun, 13 Aug 2023 22:21:08 -0700 (PDT) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id y10-20020a17090322ca00b001bb8895848bsm8364878plg.71.2023.08.13.22.21.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Aug 2023 22:21:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C From: Yuan Fu In-Reply-To: <83a5uwe27a.fsf@gnu.org> Date: Sun, 13 Aug 2023 22:20:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5EA1F5AD-C6C4-4838-8265-5A7ECF69041D@gmail.com> References: <83a5wcncj8.fsf@gnu.org> <83pm57lxbo.fsf@gnu.org> <835y6wgr77.fsf@gnu.org> <93E5B9EA-D349-4316-B314-D6994329C261@gmail.com> <83r0oplvro.fsf@gnu.org> <83y1iji7b7.fsf@gnu.org> <2134730B-05A4-4032-84B6-42FD3CDC48AE@gmail.com> <83a5uwe27a.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3731.600.7) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64442 Cc: 64442@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: -1.0 (-) > On Aug 12, 2023, at 7:59 AM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Thu, 10 Aug 2023 14:33:09 -0700 >> Cc: 64442@debbugs.gnu.org >>=20 >> I still don=E2=80=99t have a good solution. But I just realized that = we might be able to make a little compromise: what if Emacs recognizes = DEFUN, but as two separate parts (the declaration and the body), rather = than one? It=E2=80=99s hard to make it recognize DEFUN as a single = defun, but making it recognize DEFUN as two parts is easy. >>=20 >> Try this patch and see if you like the behavior. Personally I find it = quite alright. >=20 > I like this much better than what we have now, thanks. But I have a > question: can we perhaps recognize the "function" of the body as such, > and then automatically move to the previous defun, which is the right > place? The "defun" that is the body has no name, so maybe that could > be used as a sign? =20 We can easily tell the body from the declaration, but we can=E2=80=99t = easily tell whether we should automatically move forward or backward. = When point arrives at the point between the declaration and the body, = should it move to the beginning of the next defun or the beginning of = the declaration? This, plus it=E2=80=99s not straightforward to know = whether we are in between a body and a declaration. I really don=E2=80=99t= want to add even more cursed hacks into c-ts-mode.el :-) > That would allow "C-x 4 a" to work inside a DEFUN, > something that still works less reliably with this patch: you must be > in the "first defun" to get it to find the name of the function. C-x 4 a should=E2=80=99ve been fixed already. And it shouldn=E2=80=99t = rely on this fix to work. Do you have a recipe for when it doesn=E2=80=99t= work? Yuan= From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 07:59:11 2023 Received: (at 64442) by debbugs.gnu.org; 14 Aug 2023 11:59:11 +0000 Received: from localhost ([127.0.0.1]:33063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVWE2-000836-Mp for submit@debbugs.gnu.org; Mon, 14 Aug 2023 07:59:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVWE1-00082d-2r for 64442@debbugs.gnu.org; Mon, 14 Aug 2023 07:59:09 -0400 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 1qVWDv-0000sA-Ew; Mon, 14 Aug 2023 07:59:03 -0400 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=PH43il1ULEpSzk6RIx7lxyymUDh7wGgZw7SH+3W1oJk=; b=Y+/XV7pzBlp6XNlEkmW5 dWOqdOGaCZsMxojqvzYvQoqpH2CLtpIm8S4EmEVuMau9hwe62KKCT2vyPG9d8sKEa69mXm0mjkb5e 9q4KwqJ/GyXBi13fLFxcVxTZUotIzeFR2h5rHo07YpOd3Ulyh4/ZzsuxyS7MYcwKc7paFZNtWqHy/ 1FczpNdP9bOrSdCZDRdHkvEz1iQCtr0ONikquezSVYf+xaYbOancvkXWPJwIVhEq1R7IyA9KbQAk+ Pet4FZX0uzlrM+ZCZlASWcm+UTfbbyPriaXBJ/lY9eW9ycvjTUvNTMCooMkoEXf+HgVCxma6osCT2 wcNK7bKzA7kJ2A==; Date: Mon, 14 Aug 2023 14:59:02 +0300 Message-Id: <83jztxbzsp.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: <5EA1F5AD-C6C4-4838-8265-5A7ECF69041D@gmail.com> (message from Yuan Fu on Sun, 13 Aug 2023 22:20:56 -0700) Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C References: <83a5wcncj8.fsf@gnu.org> <83pm57lxbo.fsf@gnu.org> <835y6wgr77.fsf@gnu.org> <93E5B9EA-D349-4316-B314-D6994329C261@gmail.com> <83r0oplvro.fsf@gnu.org> <83y1iji7b7.fsf@gnu.org> <2134730B-05A4-4032-84B6-42FD3CDC48AE@gmail.com> <83a5uwe27a.fsf@gnu.org> <5EA1F5AD-C6C4-4838-8265-5A7ECF69041D@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: 64442 Cc: 64442@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: -3.3 (---) > From: Yuan Fu > Date: Sun, 13 Aug 2023 22:20:56 -0700 > Cc: 64442@debbugs.gnu.org > > > I like this much better than what we have now, thanks. But I have a > > question: can we perhaps recognize the "function" of the body as such, > > and then automatically move to the previous defun, which is the right > > place? The "defun" that is the body has no name, so maybe that could > > be used as a sign? > > We can easily tell the body from the declaration, but we can’t easily tell whether we should automatically move forward or backward. When point arrives at the point between the declaration and the body, should it move to the beginning of the next defun or the beginning of the declaration? This, plus it’s not straightforward to know whether we are in between a body and a declaration. I really don’t want to add even more cursed hacks into c-ts-mode.el :-) Too bad, but okay. > > That would allow "C-x 4 a" to work inside a DEFUN, > > something that still works less reliably with this patch: you must be > > in the "first defun" to get it to find the name of the function. > > C-x 4 a should’ve been fixed already. And it shouldn’t rely on this fix to work. Do you have a recipe for when it doesn’t work? Just try it with your patch. If point is inside the body, the function's name is not captured by "C-x 4 a". From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 03:31:15 2023 Received: (at 64442) by debbugs.gnu.org; 15 Aug 2023 07:31:15 +0000 Received: from localhost ([127.0.0.1]:34936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVoWJ-0002bC-2Q for submit@debbugs.gnu.org; Tue, 15 Aug 2023 03:31:15 -0400 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]:51624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVoWF-0002av-IB for 64442@debbugs.gnu.org; Tue, 15 Aug 2023 03:31:14 -0400 Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1bcad794ad4so32392745ad.3 for <64442@debbugs.gnu.org>; Tue, 15 Aug 2023 00:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692084666; x=1692689466; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=33b6+lvvffBCy7mQMHGWbY7xcJ/JYPPnFYAIbyelvwQ=; b=GgNfUcvgJUCGKKMBEC5+wLTyhqhqF23AEbVWXZHMpwnstch4umnf9uCByaWzXid5uU 0O3j4THEGPl5lguvY1DnGXNeQ432NPURfhZq9aMdwnw09guaRxmsso0P8OaVncJALJBx Ljmrd1ALKl6+Odbp0AXzo7APQsmhblPQxr0dR6BagKyUD40Lt+5v7J4zJMkJJGg2S0E7 UX4ErRNkM6YJhG+6pEVlzXBFlnVOh+rpz7n9IU42SSRaJOTXBWjjMiGUbZgWxCgMpqET 0XnNl325vGs2LpYqvJl0x/N80FHaPYJaRRLPrBfECFl/QTBSG/dh56ldpNFxf6jqsLMN Dv7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692084666; x=1692689466; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=33b6+lvvffBCy7mQMHGWbY7xcJ/JYPPnFYAIbyelvwQ=; b=SFpMOVgESgkqXCvABEiIzm4Kn1HxrTNCLy+hXMVXT9qCHELgLaQlSO1en09clq7ZjL bv2DNG+YsAwR92yuWFylzN0kpF2jGXNtk11snwe3HpLIXxr3B6FzWZGQZZoPYnDNI0/F vlyH6mIhOxrBGWh+iXge0f4PljQly66w+CUvwCPEp3tjgPSUhOgQCG88DqtR96KtU/tn 21F7nfwfPI9HLRRUk+mQeMRZOhd2KDEjD5uNer5vzK0yn4m7tBin/KdT+KhDLFbus+b8 MAfPscHYpfAaM/uJ8wzCE0ABaacDQNHTft7JV2rRm+ydVXC0kUZm7YARYThUAK8vve9/ TA4Q== X-Gm-Message-State: AOJu0Yz0BFOEmZESZPH50nsazEtvblcDT9WoCsWMseUBUEYUEkHruz4U vK+mIvfCFGBuFJBNM8zhgEU= X-Google-Smtp-Source: AGHT+IHdYrdUqrYjJidhbKytMXW5QbdgCIaBA8UFfdZr0gVxX4hGEAzjXLeFfOoamQpUH8DLmcT6MQ== X-Received: by 2002:a17:902:b907:b0:1bc:5182:1dd6 with SMTP id bf7-20020a170902b90700b001bc51821dd6mr8078296plb.35.1692084665623; Tue, 15 Aug 2023 00:31:05 -0700 (PDT) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id x12-20020a170902ec8c00b001b1a2c14a4asm10479481plg.38.2023.08.15.00.31.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2023 00:31:04 -0700 (PDT) From: Yuan Fu Message-Id: <5B9E9ADF-C632-475B-8D68-3BF0275279E5@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_2738A620-DE9F-450E-B804-7F8911A20874" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C Date: Tue, 15 Aug 2023 00:30:53 -0700 In-Reply-To: <83jztxbzsp.fsf@gnu.org> To: Eli Zaretskii References: <83a5wcncj8.fsf@gnu.org> <83pm57lxbo.fsf@gnu.org> <835y6wgr77.fsf@gnu.org> <93E5B9EA-D349-4316-B314-D6994329C261@gmail.com> <83r0oplvro.fsf@gnu.org> <83y1iji7b7.fsf@gnu.org> <2134730B-05A4-4032-84B6-42FD3CDC48AE@gmail.com> <83a5uwe27a.fsf@gnu.org> <5EA1F5AD-C6C4-4838-8265-5A7ECF69041D@gmail.com> <83jztxbzsp.fsf@gnu.org> X-Mailer: Apple Mail (2.3731.600.7) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64442 Cc: 64442@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: -1.0 (-) --Apple-Mail=_2738A620-DE9F-450E-B804-7F8911A20874 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 14, 2023, at 4:59 AM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Sun, 13 Aug 2023 22:20:56 -0700 >> Cc: 64442@debbugs.gnu.org >>=20 >>> I like this much better than what we have now, thanks. But I have a >>> question: can we perhaps recognize the "function" of the body as = such, >>> and then automatically move to the previous defun, which is the = right >>> place? The "defun" that is the body has no name, so maybe that = could >>> be used as a sign? =20 >>=20 >> We can easily tell the body from the declaration, but we can=E2=80=99t = easily tell whether we should automatically move forward or backward. = When point arrives at the point between the declaration and the body, = should it move to the beginning of the next defun or the beginning of = the declaration? This, plus it=E2=80=99s not straightforward to know = whether we are in between a body and a declaration. I really don=E2=80=99t= want to add even more cursed hacks into c-ts-mode.el :-) >=20 > Too bad, but okay. >=20 >>> That would allow "C-x 4 a" to work inside a DEFUN, >>> something that still works less reliably with this patch: you must = be >>> in the "first defun" to get it to find the name of the function. >>=20 >> C-x 4 a should=E2=80=99ve been fixed already. And it shouldn=E2=80=99t = rely on this fix to work. Do you have a recipe for when it doesn=E2=80=99t= work? >=20 > Just try it with your patch. If point is inside the body, the > function's name is not captured by "C-x 4 a=E2=80=9D. My bad, I must=E2=80=99ve been trying C-x 4 a in a different Emacs = session, which worked. Anyway, I updated the patch and C-x 4 a should = now work. Yuan --Apple-Mail=_2738A620-DE9F-450E-B804-7F8911A20874 Content-Disposition: attachment; filename=defun.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="defun.patch" Content-Transfer-Encoding: quoted-printable =46rom=20779092b28e472d17adfff92c1b9d7403aad7a106=20Mon=20Sep=2017=20= 00:00:00=202001=0AFrom:=20Yuan=20Fu=20=0ADate:=20Thu,=20= 10=20Aug=202023=2014:27:29=20-0700=0ASubject:=20[PATCH]=20Support=20= defun=20navigation=20for=20DEFUN=20in=20c-ts-mode=20(bug#64442)=0A=0A= Before=20this=20change,=20beginning/end-of-defun=20just=20ignores=20= DEFUN=20in=0Ac-ts-mode.=20After=20this=20change,=20= beginning/end-of-defun=20can=20recognize=0ADEFUN,=20but=20a=20DEFUN=20= definition=20is=20considered=20two=20defuns.=20Eg,=0A= beginning/end-of-defun=20will=20stop=20at=20(1)=20(2)=20and=20(3)=20in=20= the=20following=0Asnippet:=0A=0A(1)DEFUN=20("treesit-node-parser",=0A=20=20= =20=20=20=20=20Ftreesit_node_parser,=20Streesit_node_parser,=0A=20=20=20=20= =20=20=201,=201,=200,=0A=20=20=20=20=20=20=20doc:=20/*=20Return=20the=20= parser=20to=20which=20NODE=20belongs.=20=20*/)=0A=20=20(Lisp_Object=20= node)=0A(2){=0A=20=20CHECK_TS_NODE=20(node);=0A=20=20return=20XTS_NODE=20= (node)->parser;=0A}=0A(3)=0A=0AIdeally=20we=20want=20point=20to=20only=20= stop=20at=20(1)=20and=20(3),=20but=20that'll=20be=20a=0Alot=20harder=20= to=20do.=0A=0A*=20lisp/progmodes/c-ts-mode.el:=0A= (c-ts-mode--defun-valid-p):=20Refactor=20to=20take=20in=20account=20of=20= DEFUN=20body.=0A(c-ts-mode--emacs-defun-body-p):=20New=20function.=0A= (c-ts-base-mode):=20Add=20DEFUN=20and=20DEFUN=20body=20to=20recognized=20= types.=0A(c-ts-mode--emacs-defun-at-point):=20Now=20that=20we=20= recognize=20both=20parts=20of=0Aa=20DEFUN=20as=20defun,=20= c-ts-mode--emacs-defun-at-point=20needs=20to=20be=20updated=0Ato=20adapt=20= to=20it.=0A---=0A=20lisp/progmodes/c-ts-mode.el=20|=20115=20= +++++++++++++++++++-----------------=0A=201=20file=20changed,=2060=20= insertions(+),=2055=20deletions(-)=0A=0Adiff=20--git=20= a/lisp/progmodes/c-ts-mode.el=20b/lisp/progmodes/c-ts-mode.el=0Aindex=20= 98797bf3ce7..34a89b4dcad=20100644=0A---=20a/lisp/progmodes/c-ts-mode.el=0A= +++=20b/lisp/progmodes/c-ts-mode.el=0A@@=20-880,29=20+880,36=20@@=20= c-ts-mode--defun-name=0A=20(defun=20c-ts-mode--defun-valid-p=20(node)=0A=20= =20=20"Return=20non-nil=20if=20NODE=20is=20a=20valid=20defun=20node.=0A=20= Ie,=20NODE=20is=20not=20nested."=0A-=20=20(or=20= (c-ts-mode--emacs-defun-p=20node)=0A-=20=20=20=20=20=20(not=20(or=20(and=20= (member=20(treesit-node-type=20node)=0A-=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20'("struct_specifier"=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20"enum_specifier"=0A-=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"union_specifier"=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20"declaration"))=0A-=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20;;=20If=20NODE's=20type=20is=20one=20of=20the=20= above,=20make=20sure=20it=20is=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20;;=20top-level.=0A-=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20(treesit-node-top-level=0A-=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20node=20(rx=20(or=20= "function_definition"=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"type_definition"=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20"struct_specifier"=0A-=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20"enum_specifier"=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"union_specifier"=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20"declaration"))))=0A-=0A-=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20(and=20(equal=20(treesit-node-type=20node)=20= "declaration")=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20;;=20If=20NODE=20is=20a=20declaration,=20make=20sure=20it=20is=20not=20= a=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20;;=20= function=20declaration.=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20(equal=20(treesit-node-type=0A-=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= (treesit-node-child-by-field-name=0A-=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20node=20"declarator"))=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20"function_declarator"))))))=0A+=20=20(let=20((top-level-p=20= (lambda=20(node)=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20(not=20(treesit-node-top-level=0A+=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20node=20= (rx=20(or=20"function_definition"=0A+=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20"type_definition"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20"struct_specifier"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20"enum_specifier"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20"union_specifier"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20"declaration")))))))=0A+=20=20=20=20(pcase=20(treesit-node-type=20= node)=0A+=20=20=20=20=20=20;;=20The=20declaration=20part=20of=20a=20= DEFUN.=0A+=20=20=20=20=20=20("expression_statement"=20= (c-ts-mode--emacs-defun-p=20node))=0A+=20=20=20=20=20=20;;=20The=20body=20= of=20a=20DEFUN.=0A+=20=20=20=20=20=20("compound_statement"=20= (c-ts-mode--emacs-defun-body-p=20node))=0A+=20=20=20=20=20=20;;=20If=20= NODE's=20type=20is=20one=20of=20these=20three,=20make=20sure=20it=20is=0A= +=20=20=20=20=20=20;;=20top-level.=0A+=20=20=20=20=20=20((or=20= "struct_specifier"=0A+=20=20=20=20=20=20=20=20=20=20=20"enum_specifier"=0A= +=20=20=20=20=20=20=20=20=20=20=20"union_specifier")=0A+=20=20=20=20=20=20= =20(funcall=20top-level-p=20node))=0A+=20=20=20=20=20=20;;=20If=20NODE=20= is=20a=20declaration,=20make=20sure=20it's=20not=20a=20function=0A+=20=20= =20=20=20=20;;=20declaration=20(we=20only=20want=20function_definition)=20= and=20is=20a=0A+=20=20=20=20=20=20;;=20top-level=20declaration.=0A+=20=20= =20=20=20=20("declaration"=0A+=20=20=20=20=20=20=20(and=20(not=20(equal=20= (treesit-node-type=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20(treesit-node-child-by-field-name=0A+=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20node=20= "declarator"))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20"function_declarator"))=0A+=20=20=20=20=20=20=20=20=20=20=20= =20(funcall=20top-level-p=20node)))=0A+=20=20=20=20=20=20;;=20Other=20= types=20don't=20need=20further=20verification.=0A+=20=20=20=20=20=20(_=20= t))))=0A=20=0A=20(defun=20c-ts-mode--defun-for-class-in-imenu-p=20(node)=0A= =20=20=20"Check=20if=20NODE=20is=20a=20valid=20entry=20for=20the=20Class=20= subindex.=0A@@=20-955,6=20+962,11=20@@=20c-ts-mode--emacs-defun-p=0A=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20t)=0A=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20"DEFUN")))=0A=20=0A+(defun=20= c-ts-mode--emacs-defun-body-p=20(node)=0A+=20=20"Return=20non-nil=20if=20= NODE=20is=20the=20function=20body=20of=20a=20DEFUN."=0A+=20=20(and=20= (equal=20(treesit-node-type=20node)=20"compound_statement")=0A+=20=20=20=20= =20=20=20(c-ts-mode--emacs-defun-p=20(treesit-node-prev-sibling=20= node))))=0A+=0A=20(defun=20c-ts-mode--emacs-defun-at-point=20(&optional=20= range)=0A=20=20=20"Return=20the=20defun=20node=20at=20point.=0A=20=0A@@=20= -969,31=20+981,18=20@@=20c-ts-mode--emacs-defun-at-point=0A=20If=20RANGE=20= is=20non-nil,=20return=20(BEG=20.=20END)=20where=20BEG=20end=20END=0A=20= encloses=20the=20whole=20defun.=20=20This=20is=20for=20when=20the=20= entire=20defun=0A=20is=20required,=20not=20just=20the=20declaration=20= part=20for=20DEFUN."=0A-=20=20(or=20(when-let=20((node=20= (treesit-defun-at-point)))=0A-=20=20=20=20=20=20=20=20(if=20range=0A-=20=20= =20=20=20=20=20=20=20=20=20=20(cons=20(treesit-node-start=20node)=0A-=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20(treesit-node-end=20node))=0A-=20= =20=20=20=20=20=20=20=20=20=20=20node))=0A-=20=20=20=20=20=20(and=20= c-ts-mode-emacs-sources-support=0A-=20=20=20=20=20=20=20=20=20=20=20(let=20= ((candidate-1=20;=20For=20when=20point=20is=20in=20the=20DEFUN=20= statement.=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= (treesit-node-prev-sibling=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20(treesit-node-top-level=0A-=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20(treesit-node-at=20(point))=0A-=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20"compound_statement")))=0A-=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(candidate-2=20;=20For=20= when=20point=20is=20in=20the=20body.=0A-=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20(treesit-node-top-level=0A-=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20(treesit-node-at=20(point))=0A-=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"expression_statement")))=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20(when-let=0A-=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20((node=20(or=20(and=20= (c-ts-mode--emacs-defun-p=20candidate-1)=0A-=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= candidate-1)=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20(and=20(c-ts-mode--emacs-defun-p=20= candidate-2)=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20candidate-2))))=0A-=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20(if=20range=0A-=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20(cons=20(treesit-node-start=20node)=0A-=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= (treesit-node-end=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20(treesit-node-next-sibling=20node)))=0A-=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20node))))))=0A+=20=20(when-let*=20= ((node=20(treesit-defun-at-point))=0A+=20=20=20=20=20=20=20=20=20=20=20=20= =20=20(defun-range=20(cons=20(treesit-node-start=20node)=0A+=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20(treesit-node-end=20node))))=0A+=20=20=20=20;;=20Make=20some=20= adjustment=20for=20DEFUN.=0A+=20=20=20=20(when=20= c-ts-mode-emacs-sources-support=0A+=20=20=20=20=20=20(cond=20= ((c-ts-mode--emacs-defun-body-p=20node)=0A+=20=20=20=20=20=20=20=20=20=20= =20=20=20(setq=20node=20(treesit-node-prev-sibling=20node))=0A+=20=20=20=20= =20=20=20=20=20=20=20=20=20(setcar=20defun-range=20(treesit-node-start=20= node)))=0A+=20=20=20=20=20=20=20=20=20=20=20=20= ((c-ts-mode--emacs-defun-p=20node)=0A+=20=20=20=20=20=20=20=20=20=20=20=20= =20(setcdr=20defun-range=20(treesit-node-end=0A+=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= (treesit-node-next-sibling=20node))))))=0A+=20=20=20=20(if=20range=20= defun-range=20node)))=0A=20=0A=20(defun=20c-ts-mode-indent-defun=20()=0A=20= =20=20"Indent=20the=20current=20top-level=20declaration=20syntactically.=0A= @@=20-1111,13=20+1110,19=20@@=20c-ts-base-mode=0A=20=0A=20=20=20;;=20= Navigation.=0A=20=20=20(setq-local=20treesit-defun-type-regexp=0A-=20=20=20= =20=20=20=20=20=20=20=20=20=20=20(cons=20(regexp-opt=20= '("function_definition"=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"type_definition"=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20"struct_specifier"=0A-=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20"enum_specifier"=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"union_specifier"=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20"class_specifier"=0A-=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20"namespace_definition"))=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20= (cons=20(regexp-opt=20(append=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= '("function_definition"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= "type_definition"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"struct_specifier"=0A= +=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20"enum_specifier"=0A+=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20"union_specifier"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= "class_specifier"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= "namespace_definition")=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20(and=20= c-ts-mode-emacs-sources-support=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= '(;;=20DEFUN.=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= "expression_statement"=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= ;;=20DEFUN=20body.=0A+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= "compound_statement"))))=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20#'c-ts-mode--defun-valid-p))=0A=20=20=20(setq-local=20= treesit-defun-skipper=20#'c-ts-mode--defun-skipper)=0A=20=20=20= (setq-local=20treesit-defun-name-function=20#'c-ts-mode--defun-name)=0A= --=20=0A2.41.0=0A=0A= --Apple-Mail=_2738A620-DE9F-450E-B804-7F8911A20874 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_2738A620-DE9F-450E-B804-7F8911A20874-- From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 17 04:18:24 2023 Received: (at 64442) by debbugs.gnu.org; 17 Aug 2023 08:18:24 +0000 Received: from localhost ([127.0.0.1]:42731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWYD2-0006fU-AX for submit@debbugs.gnu.org; Thu, 17 Aug 2023 04:18:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWYD1-0006fH-GF for 64442@debbugs.gnu.org; Thu, 17 Aug 2023 04:18:23 -0400 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 1qWYCw-00011y-2G; Thu, 17 Aug 2023 04:18:18 -0400 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=gEH1m/QU3XT6izZD0d0bQM5WlNsHI8Ux/y4cmdJpG/g=; b=RZ9u6r1uFT5+wFgDHBS+ 0toNK4j07bgvcDvkJ+4sgcoW9awPC9zTnQpsd+5udqnlfHL/Owe7ojlZDzzANeqzbmIu0sxDCTOBV nReWA3zPoqttpsvsM8llPaPiyQNdRaltQZInU/GTYTwWloZo+jLmpusR9WFttKNKDGpxynDHQptkD Odv4615SpOr5Bmbo0X5iGh9Hr7p5aSdqD+El4HKOL+P3ypaA1c4B62ZOBvV3AFUSLDLsSJWUdS6Ot iN8SgK54FHmdtqXr+cCk/zNviEJmqjlQs584QpAxFCPoNjqi9+mU7kS4zQ1SfzeXPdvW2KB9C44wx dtJnbGhP7+jmXQ==; Date: Thu, 17 Aug 2023 11:18:22 +0300 Message-Id: <83wmxu5bg1.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: <5B9E9ADF-C632-475B-8D68-3BF0275279E5@gmail.com> (message from Yuan Fu on Tue, 15 Aug 2023 00:30:53 -0700) Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C References: <83a5wcncj8.fsf@gnu.org> <83pm57lxbo.fsf@gnu.org> <835y6wgr77.fsf@gnu.org> <93E5B9EA-D349-4316-B314-D6994329C261@gmail.com> <83r0oplvro.fsf@gnu.org> <83y1iji7b7.fsf@gnu.org> <2134730B-05A4-4032-84B6-42FD3CDC48AE@gmail.com> <83a5uwe27a.fsf@gnu.org> <5EA1F5AD-C6C4-4838-8265-5A7ECF69041D@gmail.com> <83jztxbzsp.fsf@gnu.org> <5B9E9ADF-C632-475B-8D68-3BF0275279E5@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: 64442 Cc: 64442@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: -3.3 (---) > From: Yuan Fu > Date: Tue, 15 Aug 2023 00:30:53 -0700 > Cc: 64442@debbugs.gnu.org > > >>> That would allow "C-x 4 a" to work inside a DEFUN, > >>> something that still works less reliably with this patch: you must be > >>> in the "first defun" to get it to find the name of the function. > >> > >> C-x 4 a should’ve been fixed already. And it shouldn’t rely on this fix to work. Do you have a recipe for when it doesn’t work? > > > > Just try it with your patch. If point is inside the body, the > > function's name is not captured by "C-x 4 a”. > > My bad, I must’ve been trying C-x 4 a in a different Emacs session, which worked. Anyway, I updated the patch and C-x 4 a should now work. Thanks, LGTM. Please install on the emacs-29 branch, and close the bug when you do. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 19 18:01:14 2023 Received: (at 64442-done) by debbugs.gnu.org; 19 Aug 2023 22:01:14 +0000 Received: from localhost ([127.0.0.1]:52416 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXU0Q-000444-Bz for submit@debbugs.gnu.org; Sat, 19 Aug 2023 18:01:14 -0400 Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]:58692) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXU0N-00043q-SM for 64442-done@debbugs.gnu.org; Sat, 19 Aug 2023 18:01:13 -0400 Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-68a3f0a7092so90670b3a.1 for <64442-done@debbugs.gnu.org>; Sat, 19 Aug 2023 15:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692482464; x=1693087264; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=I6ixjnqzrPMqFvIL0gsNBuePkLQva1vJo/dq+XqW8Tc=; b=IWAgS7KfmPG8S9IPGiHkpRvpSzaSwEeck6/AUa3IJ85dA+y65rtPFBz5wCWU+nUCln M5YELGUtXI+ykD+1LikwLR93C+vl71VPWvEEPnCaHALr7dFyvf8IjDORBwKCQGjn0cli YosxOWS/cEHDYq8AcuWJCNAjijHY0kchglSeO3bMJaM175lB00ueI/bMRBQLl6dFvfJ0 UOm8DW4K9eS0uBG5uEj0esZ95mrBglitHxnyp2U7fAe7wKTSgU8cedXqCe4H2EtYH1Vu MSlw1GLOxlEJAJmC29glZcx0lhGptFMuvvNs20hfRXtqg3xLM9aS5JQBJQX5rZuWKguo hDRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692482464; x=1693087264; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=I6ixjnqzrPMqFvIL0gsNBuePkLQva1vJo/dq+XqW8Tc=; b=WSBA7iWSXiHI8Q8iisO+MkUfe+gc84EUBujikPNh6gw5Bc7cozMgMVyosXQ6IeKhc6 /uLesyDnTqL40rMX0+ps7lcbC5BtHVqlnPM6Cvk/ego/7KX9g405RJwKABaaO5iezk+F b0JwMGOOfC6Q3l2mmRruzHSs6zw3tlYwakVPEFNNQ1lzeg7+sQ9b3xnVFC2/KdRCI2pm 1JaEIC1v0xqxrkZ2PAgMaZ3ZMUkoE30zfoPwOMlHyTwUqg1h2kLcQATNzru1oDkpv/Ef 0DVzkomxBgFHeXfVPjbmQwdMr9OzbGRnjZ+l2we9a83THuYZ1LdYgw/tAqUy4oTYxvx2 EyFg== X-Gm-Message-State: AOJu0YxFefjUhP6Ckc7Z+0hn92Hm+x2U6CfX1rAVOoO4SDIXlb9MJrFs 2VDY9gEKofXIVi+/hcuod4Y= X-Google-Smtp-Source: AGHT+IHhjgmpDg2Z4RKl2R7k6ok8VCjViQoFYO+beckTNOs65Pb259aLqbemy1EKu3UZWLgBd2PiQw== X-Received: by 2002:a05:6a20:4282:b0:137:40ba:d91f with SMTP id o2-20020a056a20428200b0013740bad91fmr4567298pzj.10.1692482464414; Sat, 19 Aug 2023 15:01:04 -0700 (PDT) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id q18-20020a639812000000b00564be149a15sm3725892pgd.65.2023.08.19.15.01.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Aug 2023 15:01:03 -0700 (PDT) From: Yuan Fu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: bug#64442: 29.0.92; treesit-beginning-of-defun fails in DEFUN functions in C Message-Id: Date: Sat, 19 Aug 2023 15:00:52 -0700 To: Eli Zaretskii X-Mailer: Apple Mail (2.3731.600.7) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64442-done Cc: 64442-done@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: -1.0 (-) Eli Zaretskii writes: >> From: Yuan Fu >> Date: Tue, 15 Aug 2023 00:30:53 -0700 >> Cc: 64442@debbugs.gnu.org >>=20 >> >>> That would allow "C-x 4 a" to work inside a DEFUN, >> >>> something that still works less reliably with this patch: you >> >>> must be >> >>> in the "first defun" to get it to find the name of the function. >> >>=20 >> >> C-x 4 a should=E2=80=99ve been fixed already. And it shouldn=E2=80=99= t rely on >> >> this fix to work. Do you have a recipe for when it doesn=E2=80=99t = work? >> >=20 >> > Just try it with your patch. If point is inside the body, the >> > function's name is not captured by "C-x 4 a=E2=80=9D. >>=20 >> My bad, I must=E2=80=99ve been trying C-x 4 a in a different Emacs = session, >> which worked. Anyway, I updated the patch and C-x 4 a should now >> work. > > Thanks, LGTM. Please install on the emacs-29 branch, and close the > bug when you do. Pushed, thanks. Yuan From unknown Fri Aug 15 04:08:34 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 17 Sep 2023 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator