From unknown Tue Jun 17 20:19:45 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#77727 <77727@debbugs.gnu.org> To: bug#77727 <77727@debbugs.gnu.org> Subject: Status: tsx-ts-mode: fill-paragraph doesn't work for doc-comments Reply-To: bug#77727 <77727@debbugs.gnu.org> Date: Wed, 18 Jun 2025 03:19:45 +0000 retitle 77727 tsx-ts-mode: fill-paragraph doesn't work for doc-comments reassign 77727 emacs submitter 77727 Konstantin Kharlamov severity 77727 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 04:11:06 2025 Received: (at submit) by debbugs.gnu.org; 11 Apr 2025 08:11:06 +0000 Received: from localhost ([127.0.0.1]:48555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u39Te-0001Mo-C6 for submit@debbugs.gnu.org; Fri, 11 Apr 2025 04:11:06 -0400 Received: from lists.gnu.org ([2001:470:142::17]:42280) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u39Tc-0001MC-FW for submit@debbugs.gnu.org; Fri, 11 Apr 2025 04:11:04 -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 1u39TK-00028L-GF for bug-gnu-emacs@gnu.org; Fri, 11 Apr 2025 04:10:48 -0400 Received: from forward101b.mail.yandex.net ([178.154.239.148]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u39TH-0005XU-Pk for bug-gnu-emacs@gnu.org; Fri, 11 Apr 2025 04:10:46 -0400 Received: from mail-nwsmtp-smtp-production-main-98.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-98.sas.yp-c.yandex.net [IPv6:2a02:6b8:c16:123:0:640:744c:0]) by forward101b.mail.yandex.net (Yandex) with ESMTPS id C58BF60E89 for ; Fri, 11 Apr 2025 11:10:35 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-98.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id YAbdlO1LfGk0-wF4mgWN4; Fri, 11 Apr 2025 11:10:35 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1744359035; bh=GkyyQjfzTyaR56BxnSfy5Ttp0N0XQvHtRxyS01y9ItA=; h=Date:To:From:Subject:Message-ID; b=CyzPXmFNCkpaYC2EHXu1xhDZX+oguilXPH5AP/la3XU7Eqr+3g5b+0xxPkBlUYZHX xB8/WczdRE/qBaU+TuF3iqgXNxSpAVeNzHV1p/LwJY4YOPFAgNc5xd7vC+rncSe3zr 5b7juuwDDgFofQ9x3VrF2lKY9jV+4uSWA7wUbfW8= Authentication-Results: mail-nwsmtp-smtp-production-main-98.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Subject: tsx-ts-mode: fill-paragraph doesn't work for doc-comments From: Konstantin Kharlamov To: bug-gnu-emacs@gnu.org Date: Fri, 11 Apr 2025 11:10:34 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.0 MIME-Version: 1.0 Received-SPF: pass client-ip=178.154.239.148; envelope-from=hi-angel@yandex.ru; helo=forward101b.mail.yandex.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) 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.0 (/) Steps to reproduce: 1. Open `test.tsx` with the following content: // File description /** * Lorem ipsum dolor sit amet consectetur adipiscing elit. Quisque fauc= ibus ex sapien vitae pellentesque sem placerat. In id cursus mi pretium tel= lus duis convallis. */ 2. Try to "fill" the Lorem ipsum text. Result: nothing changes, the text doesn't get "filled". --------- I dug into it, the bug resides in the following condition in `c-ts-common--fill-paragraph`: =E2=80=A6 ;; In rust, NODE will be the body of a comment, and the ;; parent will be the whole comment. (if-let* ((start (treesit-node-start (treesit-node-parent node)))) (save-excursion (goto-char start) (looking-at "//")))) =E2=80=A6 The problem is that "(treesit-node-start (treesit-node-parent node))" retur= ns 1. That happens disregarding the amount of code between the "// File descripti= on" line and where "/* Lorem ipsum=E2=80=A6" is. In the actual code there's 51 = lines in between. Why treesit-node-start does that I don't know, so I decided to report it. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 04:34:54 2025 Received: (at 77727) by debbugs.gnu.org; 11 Apr 2025 08:34:54 +0000 Received: from localhost ([127.0.0.1]:48606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u39qf-0002TX-QR for submit@debbugs.gnu.org; Fri, 11 Apr 2025 04:34:54 -0400 Received: from forward101d.mail.yandex.net ([178.154.239.212]:44004) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u39qb-0002T5-VO for 77727@debbugs.gnu.org; Fri, 11 Apr 2025 04:34:51 -0400 Received: from mail-nwsmtp-smtp-production-main-73.iva.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-73.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:bca8:0:640:45be:0]) by forward101d.mail.yandex.net (Yandex) with ESMTPS id D24CB60B2D; Fri, 11 Apr 2025 11:34:40 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-73.iva.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id dYbZuD1LfuQ0-TOTpxkge; Fri, 11 Apr 2025 11:34:40 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1744360480; bh=OxNmKnE7bmjeAy7N+VD/jkutZV564qJ9ihHoKF6v4bo=; h=Date:To:From:Subject:Message-ID; b=OoBUGStFjCbe6swjrKuYYqAJkWybNV0252bM9AqHBVTtTx1poSOgmAe0Wr17jumo6 W1SPaT92Dm+47huL6EBfOt3lpQDwdIROu7O98vtFbA2/EsyDjl0LCDf0qIKXC78siE Z4hj0fZtsbe4hPk/YYzPyAJ8SREbwWaaBgg+n1R4= Authentication-Results: mail-nwsmtp-smtp-production-main-73.iva.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> Subject: bug#77727: tsx-ts-mode: fill-paragraph doesn't work for doc-comments From: Konstantin Kharlamov To: 77727@debbugs.gnu.org, casouri@gmail.com Date: Fri, 11 Apr 2025 11:34:38 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.0 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77727 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 (-) CC: Yuan Fu as the author of the code in question. What happens in the code makes sense: since the comment resides at top- level, the parent of any top-level statement (returned by (treesit- node-parent node)) is, well, beginning of a buffer. So the question is, why the check works that way. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 11 07:51:58 2025 Received: (at 77727) by debbugs.gnu.org; 11 Apr 2025 11:51:58 +0000 Received: from localhost ([127.0.0.1]:49223 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u3CvO-0007Nq-6d for submit@debbugs.gnu.org; Fri, 11 Apr 2025 07:51:58 -0400 Received: from forward501a.mail.yandex.net ([2a02:6b8:c0e:500:1:45:d181:d501]:35044) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u3CvJ-0007NH-Fi for 77727@debbugs.gnu.org; Fri, 11 Apr 2025 07:51:55 -0400 Received: from mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net [IPv6:2a02:6b8:c1d:4795:0:640:c576:0]) by forward501a.mail.yandex.net (Yandex) with ESMTPS id 8E3D461425; Fri, 11 Apr 2025 14:51:45 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id ipea8O2Lb4Y0-KtWdhMUs; Fri, 11 Apr 2025 14:51:45 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1744372305; bh=DtAbcyktUtXeSMaVF/meUyml3kVhAUFAFEfMl/nFZ9Y=; h=In-Reply-To:Date:References:To:From:Subject:Message-ID; b=J+46LgusO1J2KTwx1CtdluHHLaFQ0NwsKcVvVOdjd8/+1BLcNREwlZw3chnRmB4Ly mQ5mboMs3m4nn8UKmbXpDfl8/6+SJ2pUx4tPdSIGtMmkIfKDEoZAC8J3DC/8W5whou O88j2sjJOY9TvR3udzzXTvefhyzsaHoxJz3eNSTs= Authentication-Results: mail-nwsmtp-smtp-production-main-81.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Subject: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727) From: Konstantin Kharlamov To: 77727@debbugs.gnu.org, casouri@gmail.com Date: Fri, 11 Apr 2025 14:51:44 +0300 In-Reply-To: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> References: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> Content-Type: multipart/mixed; boundary="=-wXja4Q+59jsSA7IBHrB1" User-Agent: Evolution 3.56.0 MIME-Version: 1.0 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 77727 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.7 (-) --=-wXja4Q+59jsSA7IBHrB1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2025-04-11 at 11:34 +0300, Konstantin Kharlamov wrote: > CC: Yuan Fu as the author of the code in question. >=20 > What happens in the code makes sense: since the comment resides at > top- > level, the parent of any top-level statement (returned by (treesit- > node-parent node)) is, well, beginning of a buffer. >=20 > So the question is, why the check works that way. Please see the attached patch, it'd seem this is exactly the fix that's expected here. Basically, the problematic check is specific to Rust treesitter mode, so shouldn't be executed in other languages. The patch factors out the entire check to a separate function and adds additional condition of (eq major-mode 'rust-ts-mode). Tested in tsx-ts-mode, it fixes the problem. --=-wXja4Q+59jsSA7IBHrB1 Content-Disposition: attachment; filename="1.patch" Content-Type: text/x-patch; name="1.patch"; charset="UTF-8" Content-Transfer-Encoding: base64 RnJvbSBjNWNlYWJiMzczOTM5YzMwZDJmMjc4NmYxYjA2ZGQwOTE1MjMyMTQ4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBLb25zdGFudGluIEtoYXJsYW1vdiA8SGktQW5nZWxAeWFuZGV4 LnJ1PgpEYXRlOiBGcmksIDExIEFwciAyMDI1IDE0OjM4OjI0ICswMzAwClN1YmplY3Q6IFtQQVRD SF0gTGltaXQgcnVzdC10cy1zcGVjaWZpYyBjb21tZW50LXN0YXJ0IGNoZWNrIHRvIHJ1c3QtdHMK IChidWcjNzc3MjcpCgpUaGUgY2hlY2sgYCh0cmVlc2l0LW5vZGUtc3RhcnQgKHRyZWVzaXQtbm9k ZS1wYXJlbnQgbm9kZSkpJyBpcwpzcGVjaWZpYyB0byBSdXN0IG1vZGUgKGFzIG1lbnRpb25lZCBp biB0aGUgY29tbWVudCksIGFuZCBpbiBvdGhlcgpsYW5ndWFnZXMgaXQgd2FzIHdyb25nIHRvIGV4 ZWN1dGUuICBFLmcuIGluIHRzeC10cy1tb2RlIGl0IHdhcyBnaXZpbmcKdGhlIHN0YXJ0IG9mIHRo ZSBidWZmZXIsIGFuZCB0aGVuIGlmIGJ1ZmZlciBzdGFydGVkIHdpdGggYC8vJyB0aGUKd3Jvbmcg YnJhbmNoIG9mIGV4ZWN1dGlvbiB3YXMgYmVpbmcgdGFrZW4uICBGaXggdGhhdCBieSBsaW1pdGlu ZyB0aGUKY2hlY2sgdG8gcnVzdC10cy1tb2RlIHdoaWNoIGlzIHRoZSBvbmx5IG9uZSB3aGVyZSBp dCBtYXR0ZXJzLgoKKiBsaXNwL3Byb2dtb2Rlcy9jLXRzLWNvbW1vbi5lbCAoYy10cy1jb21tb24t LWZpbGwtcGFyYWdyYXBoKTogRmFjdG9yCm91dCBgYy10cy1jb21tb24tLWNvbW1lbnQtc3RhcnQt aXMtLy8nIGFuZCByZWR1Y2UgY29tbWVudCBsZW5ndGguCihjLXRzLWNvbW1vbi0tY29tbWVudC1z dGFydC1pcy0vLyk6IE5ldyBmdW5jdGlvbiwgd2hvc2UgYm9keSBpcyB0YWtlbgpmcm9tIGBjLXRz LWNvbW1vbi0tZmlsbC1wYXJhZ3JhcGgnLiAgVGhlIGNoYW5nZXMgdGhhdCB3ZXJlIGRvbmU6CjEu IFRoZSBydXN0LXNwZWNpZmljIGNoZWNrIGlzIG5vdyBsaW1pdGVkIHRvIHJ1c3QtdHMtbW9kZSwg Mi4gVGhlCmV4cGxhbmF0aW9uIGNvbW1lbnQgaXMgbWFkZSBtb3JlIGV4cGxpY2l0LgotLS0KIGxp c3AvcHJvZ21vZGVzL2MtdHMtY29tbW9uLmVsIHwgMjcgKysrKysrKysrKysrKysrLS0tLS0tLS0t LS0tCiAxIGZpbGUgY2hhbmdlZCwgMTUgaW5zZXJ0aW9ucygrKSwgMTIgZGVsZXRpb25zKC0pCgpk aWZmIC0tZ2l0IGEvbGlzcC9wcm9nbW9kZXMvYy10cy1jb21tb24uZWwgYi9saXNwL3Byb2dtb2Rl cy9jLXRzLWNvbW1vbi5lbAppbmRleCA3MWMxNzc3ODhhOC4uYzE2YTFmMGM0NjcgMTAwNjQ0Ci0t LSBhL2xpc3AvcHJvZ21vZGVzL2MtdHMtY29tbW9uLmVsCisrKyBiL2xpc3AvcHJvZ21vZGVzL2Mt dHMtY29tbW9uLmVsCkBAIC0xMTMsNiArMTEzLDE5IEBAIGMtdHMtY29tbW9uLS1jb21tZW50LXJl Z2V4cAogICAocnggKG9yICJjb21tZW50IiAibGluZV9jb21tZW50IiAiYmxvY2tfY29tbWVudCIp KQogICAiUmVnZXhwIHBhdHRlcm4gdGhhdCBtYXRjaGVzIGEgY29tbWVudCBpbiBDLWxpa2UgbGFu Z3VhZ2VzLiIpCiAKKyhkZWZ1biBjLXRzLWNvbW1vbi0tY29tbWVudC1zdGFydC1pcy0vLyAobm9k ZSkKKyAgKG9yIChzYXZlLWV4Y3Vyc2lvbgorICAgICAgICAoZ290by1jaGFyICh0cmVlc2l0LW5v ZGUtc3RhcnQgbm9kZSkpCisgICAgICAgIChsb29raW5nLWF0ICIvLyIpKQorICAgICAgOzsgSW4g cnVzdCwgTk9ERSBzdGFydCBtYXkgYmUgaW5zaWRlIHRoZSBjb21tZW50LCB0aGUgcGFyZW50IHRo ZW4KKyAgICAgIDs7IHdpbGwgYmUgc3RhcnQgb2YgdGhlIGNvbW1lbnQuCisgICAgICAod2hlbi1s ZXQqICgoXyAoZXEgbWFqb3ItbW9kZSAncnVzdC10cy1tb2RlKSkKKyAgICAgICAgICAgICAgICAg IChzdGFydCAodHJlZXNpdC1ub2RlLXN0YXJ0CisgICAgICAgICAgICAgICAgICAgICAgICAgICh0 cmVlc2l0LW5vZGUtcGFyZW50IG5vZGUpKSkpCisgICAgICAgIChzYXZlLWV4Y3Vyc2lvbgorICAg ICAgICAgIChnb3RvLWNoYXIgc3RhcnQpCisgICAgICAgICAgKGxvb2tpbmctYXQgIi8vIikpKSkp CisKIChkZWZ1biBjLXRzLWNvbW1vbi0tZmlsbC1wYXJhZ3JhcGggKCZvcHRpb25hbCBhcmcpCiAg ICJGaWxsaW5nIGZ1bmN0aW9uIGZvciBgYy10cy1jb21tb24nLgogQVJHIGlzIHBhc3NlZCB0byBg ZmlsbC1wYXJhZ3JhcGgnLiIKQEAgLTEyMiwyMCArMTM1LDEwIEBAIGMtdHMtY29tbW9uLS1maWxs LXBhcmFncmFwaAogICAgIChsZXQgKChub2RlICh0cmVlc2l0LW5vZGUtYXQgKHBvaW50KSkpKQog ICAgICAgKHdoZW4gKHN0cmluZy1tYXRjaC1wIGMtdHMtY29tbW9uLS1jb21tZW50LXJlZ2V4cAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICh0cmVlc2l0LW5vZGUtdHlwZSBub2RlKSkKLSAg ICAgICAgKGlmIChvciAoc2F2ZS1leGN1cnNpb24KLSAgICAgICAgICAgICAgICAgIChnb3RvLWNo YXIgKHRyZWVzaXQtbm9kZS1zdGFydCBub2RlKSkKLSAgICAgICAgICAgICAgICAgIChsb29raW5n LWF0ICIvLyIpKQotICAgICAgICAgICAgICAgIDs7IEluIHJ1c3QsIE5PREUgd2lsbCBiZSB0aGUg Ym9keSBvZiBhIGNvbW1lbnQsIGFuZCB0aGUKLSAgICAgICAgICAgICAgICA7OyBwYXJlbnQgd2ls bCBiZSB0aGUgd2hvbGUgY29tbWVudC4KLSAgICAgICAgICAgICAgICAoaWYtbGV0KiAoKHN0YXJ0 ICh0cmVlc2l0LW5vZGUtc3RhcnQKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAo dHJlZXNpdC1ub2RlLXBhcmVudCBub2RlKSkpKQotICAgICAgICAgICAgICAgICAgICAoc2F2ZS1l eGN1cnNpb24KLSAgICAgICAgICAgICAgICAgICAgICAoZ290by1jaGFyIHN0YXJ0KQotICAgICAg ICAgICAgICAgICAgICAgIChsb29raW5nLWF0ICIvLyIpKSkpCisgICAgICAgIChpZiAoYy10cy1j b21tb24tLWNvbW1lbnQtc3RhcnQtaXMtLy8gbm9kZSkKICAgICAgICAgICAgIChmaWxsLWNvbW1l bnQtcGFyYWdyYXBoIGFyZykKICAgICAgICAgICAoYy10cy1jb21tb24tLWZpbGwtYmxvY2stY29t bWVudCBhcmcpKSkKLSAgICAgIDs7IFJldHVybiB0IHNvIGBmaWxsLXBhcmFncmFwaCcgZG9lc24n dCBhdHRlbXB0IHRvIGZpbGwgYnkKLSAgICAgIDs7IGl0c2VsZi4KKyAgICAgIDs7IFJldHVybiB0 IHNvIGBmaWxsLXBhcmFncmFwaCcgZG9lc24ndCBhdHRlbXB0IHRvIGZpbGwgYnkgaXRzZWxmLgog ICAgICAgdCkpKQogCiAoZGVmdW4gYy10cy1jb21tb24tLWZpbGwtYmxvY2stY29tbWVudCAoJm9w dGlvbmFsIGFyZykKLS0gCjIuNDkuMAoK --=-wXja4Q+59jsSA7IBHrB1-- From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 17 01:58:57 2025 Received: (at 77727) by debbugs.gnu.org; 17 Apr 2025 05:58:57 +0000 Received: from localhost ([127.0.0.1]:45460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u5IH2-00054h-Sx for submit@debbugs.gnu.org; Thu, 17 Apr 2025 01:58:57 -0400 Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]:56321) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u5IH0-000549-64 for 77727@debbugs.gnu.org; Thu, 17 Apr 2025 01:58:55 -0400 Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-2ff64550991so217632a91.0 for <77727@debbugs.gnu.org>; Wed, 16 Apr 2025 22:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744869528; x=1745474328; 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=wgFk5vSuTj6LHfMKEmUtzW4u5d8KK62Xw7mHwImdm4g=; b=hCOlm6KYfgx8hewRxZeOSZ9Qcp7flCrwSOh8MEygSHQPRut+fDq6DSjjJa4qDfqoDp yOTAF3QA2QFFbvmeXv+VIAudj3WqjNmT4U/qsp4sQjOzVxdYNh0eyUN0obf1UmT8bEVU QG9QZMVftJjn2SPfqMwiPqQCtAQtl+FR5N4ajqDBAKeCHsPjK2XNmTXilfDHxCiCBI4m eoH5MN8QawaiXPaeTl0szU0Ghlcn2Xlbi6h16NNZ0A0OvvKVo2mP4foj2OsFXAhmUsMZ kudD5tRv/fmjzoFn+9kWnPMSRdsIU4A8HEmk8XyB905fCokfNh6AtFsTRwaKpzEwtEm+ IbEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744869528; x=1745474328; 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=wgFk5vSuTj6LHfMKEmUtzW4u5d8KK62Xw7mHwImdm4g=; b=qWMYElCNCTXC4AcBADmhzqnW8hBxjV8wY+FfYHxANphUsjwZm7PwQB5bkp/0heisb/ pQd5VREtYQ//nl84hnCDRVkx8SMEsu7dK1J+mCF1KGUDW+XC3pO4laIf34qPxRaAO0qz 5/Oz28I5R2BwVDDIXVVVc/OgU8JV6O+peIU7o3nKnwOP6iS//VKPT10Cv+ywjRTyvtQR AUy542MmSVgFmdC43kDmq6OOGEdnw5qaFTcUqaSmT30WtU5PQlkWix538COs8CGNAj61 9RZ6WE7Ik7JYJaN+NGz7TsTrP9gZjP6gw1gjOHp3ZX2Kuzq6fbTuistQKc067ZDEYrE3 2IPw== X-Gm-Message-State: AOJu0YxCoYcBRbWFhwXSD1//vI1DuLWgmPSnnrsOGFHKEDfYVTJ0rcvd jMNVaeOvyP+5sXl6qRGfSrAjCFl3YpNkBw1DfYIHcO9oVDuTx3oK X-Gm-Gg: ASbGncupVwrMAOrz9PlczcfrV5qkzyTHkaTmVJedrf9nY7ByuggSB7z3U8FP4Tw1hqo ML4OqP+kGFB2ayYm3p5lULnm1kL3JBrc+lIDfphTNmStFFYxAfXQvA7bqcHiyGgrZSMupMyujBh AY3UF2PNHyKrMjwjZXzmRvb2QJD2bGkWU/CK8iZ5HQ0rV4Kkpl1/0Al9zhj3H4gVwisG3v8Viow TeB5oe2VfvEZ8jh/RcCKPmHEi4bbkFvAOmYjynvToop+vsnluSbQUN9AIQt1fVdkggK2ZwBKBpM BstbDInYeue9ElxLB7aA6smyH1EEfW8pufzwN8CzLpAZRRVES7NCON9f1n66sZSo X-Google-Smtp-Source: AGHT+IGP9KrTzMC5DrIDNSxoL6l4hlX1N243Hpk0926Qi37cTmaoQSetvAHdG2w/3R5/HH56tS1+rg== X-Received: by 2002:a17:90b:524c:b0:2ee:b875:6d30 with SMTP id 98e67ed59e1d1-30863f19b4emr7619789a91.9.1744869527746; Wed, 16 Apr 2025 22:58:47 -0700 (PDT) Received: from smtpclient.apple ([2601:646:8f81:6120:9c26:1394:9c81:74c2]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-30861212fc9sm2744763a91.26.2025.04.16.22.58.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Apr 2025 22:58:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727) From: Yuan Fu In-Reply-To: Date: Wed, 16 Apr 2025 22:58:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <34D65C29-C4E5-44DE-BC8A-560381945752@gmail.com> References: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> To: Konstantin Kharlamov X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77727 Cc: 77727@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 Apr 11, 2025, at 4:51=E2=80=AFAM, Konstantin Kharlamov = wrote: >=20 > On Fri, 2025-04-11 at 11:34 +0300, Konstantin Kharlamov wrote: >> CC: Yuan Fu as the author of the code in question. >>=20 >> What happens in the code makes sense: since the comment resides at >> top- >> level, the parent of any top-level statement (returned by (treesit- >> node-parent node)) is, well, beginning of a buffer. >>=20 >> So the question is, why the check works that way. >=20 > Please see the attached patch, it'd seem this is exactly the fix = that's > expected here. Basically, the problematic check is specific to Rust > treesitter mode, so shouldn't be executed in other languages. The = patch > factors out the entire check to a separate function and adds = additional > condition of (eq major-mode 'rust-ts-mode). >=20 > Tested in tsx-ts-mode, it fixes the problem. > <1.patch> Thanks! Your analysis is correct. But I don=E2=80=99t want to hard-code = rust-ts-mode in the function, since modes with other names can very well = use rust parser. I pushed 9d43715baa5 that operates in the similar vein = as your patch. Instead of checking for the current major mode, I tighten = the condition by adding an additional check that ensure the parent node = is a comment node. So now if the parent node is the root node (as in = your initial example), the condition should fail. Please see if it fixes = your problem. Yuan From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 17 03:12:58 2025 Received: (at 77727) by debbugs.gnu.org; 17 Apr 2025 07:12:58 +0000 Received: from localhost ([127.0.0.1]:45595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u5JQf-00051O-Q9 for submit@debbugs.gnu.org; Thu, 17 Apr 2025 03:12:58 -0400 Received: from forward501b.mail.yandex.net ([178.154.239.145]:55680) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u5JQb-00050P-Jw for 77727@debbugs.gnu.org; Thu, 17 Apr 2025 03:12:55 -0400 Received: from mail-nwsmtp-smtp-production-canary-88.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-canary-88.sas.yp-c.yandex.net [IPv6:2a02:6b8:c28:7d5:0:640:285a:0]) by forward501b.mail.yandex.net (Yandex) with ESMTPS id 6B4C3618C7; Thu, 17 Apr 2025 10:12:44 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-canary-88.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id hCD6vqBLdCg0-s1Iyrqd3; Thu, 17 Apr 2025 10:12:44 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1744873964; bh=rPhhgk+i52kNZd8vHq6YigGZBY4yUgz47JO6+0jTwUA=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=DcZ1rgTBf1VfVjZAOSrjWr+JoeZ6FmG3WOiPcWj3mApi+Tu+T9weCbAaHI8rAuuxF ufgMuFT4a45elTUZD546YKp3EuxN1Q4WeXB1XAyUCN+fJLGCCK/b7/zDCWyevIq7z2 T9yLWy3SrqumNMeSS6GL73sYxNDeArnwwzFdmLvI= Authentication-Results: mail-nwsmtp-smtp-production-canary-88.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <10ba685f25598d5df5a496940a2a350a89040a3b.camel@yandex.ru> Subject: Re: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727) From: Konstantin Kharlamov To: Yuan Fu Date: Thu, 17 Apr 2025 10:12:43 +0300 In-Reply-To: <34D65C29-C4E5-44DE-BC8A-560381945752@gmail.com> References: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> <34D65C29-C4E5-44DE-BC8A-560381945752@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.0 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77727 Cc: 77727@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 Wed, 2025-04-16 at 22:58 -0700, Yuan Fu wrote: > > > > On Apr 11, 2025, at 4:51=E2=80=AFAM, Konstantin Kharlamov > > wrote: > > > > On Fri, 2025-04-11 at 11:34 +0300, Konstantin Kharlamov wrote: > > > CC: Yuan Fu as the author of the code in question. > > > > > > What happens in the code makes sense: since the comment resides > > > at > > > top- > > > level, the parent of any top-level statement (returned by > > > (treesit- > > > node-parent node)) is, well, beginning of a buffer. > > > > > > So the question is, why the check works that way. > > > > Please see the attached patch, it'd seem this is exactly the fix > > that's > > expected here. Basically, the problematic check is specific to Rust > > treesitter mode, so shouldn't be executed in other languages. The > > patch > > factors out the entire check to a separate function and adds > > additional > > condition of (eq major-mode 'rust-ts-mode). > > > > Tested in tsx-ts-mode, it fixes the problem. > > <1.patch> > > Thanks! Your analysis is correct. But I don=E2=80=99t want to hard-code r= ust- > ts-mode in the function, since modes with other names can very well > use rust parser. I pushed 9d43715baa5 that operates in the similar > vein as your patch. Instead of checking for the current major mode, I > tighten the condition by adding an additional check that ensure the > parent node is a comment node. So now if the parent node is the root > node (as in your initial example), the condition should fail. Please > see if it fixes your problem. > > Yuan Well, FWIW latest master as of 2925ff6c538 doesn't even start for me: =CE=BB emacs -Q Loading loadup.el (source)... Dump mode: nil Using load-path (/usr/share/emacs/31.0.50/lisp /usr/share/emacs/31.0.50= /lisp/emacs-lisp /usr/share/emacs/31.0.50/lisp/progmodes /usr/share/emacs/3= 1.0.50/lisp/language /usr/share/emacs/31.0.50/lisp/international /usr/share= /emacs/31.0.50/lisp/textmodes /usr/share/emacs/31.0.50/lisp/vc) Loading emacs-lisp/debug-early... Symbol's function definition is void: file-name-sans-extension I tried jumping down between some commits and rebuilding, but it doesn't go away. Anyway, if you tested that the steps-to-reproduce don't reproduce the problem anymore with you commit, I guess it's fine to close the bug. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 17 03:38:10 2025 Received: (at 77727) by debbugs.gnu.org; 17 Apr 2025 07:38:10 +0000 Received: from localhost ([127.0.0.1]:45625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u5Jp3-0007tZ-Vo for submit@debbugs.gnu.org; Thu, 17 Apr 2025 03:38:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60916) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u5Joz-0007rl-83 for 77727@debbugs.gnu.org; Thu, 17 Apr 2025 03:38:06 -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 1u5Jot-0003sq-74; Thu, 17 Apr 2025 03:37:59 -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=huR8OLuxYcH9piCoJ/CPUY2/MMlovPtcyKHYvzLTWvE=; b=HMcw92JATTdcODSWZO0I 4gcyxv5KdTe8cYF/Jxcl4BST5Q2MWGOVRDaAbDiscW2muMuF2tyYBPdJU1CJq/9qqF6hJUjW7WBca qdRwdCqIN7HZSn2n/H/JVDSr3miWQwra21CpeBy71ceCQlADpR0g7ScirSenb7MiZlpozYwZdb7ml k6GIuDJBgKagVLG9rWzb861ZKdzaPdvUVzsIjJdDVpv12Z+sorTWS+18VZe7d9n/uzhwoQ92ai5RG LYcXrxa1aoPiCHd32e6xDGr41FwF3cIn3dM6ZZqrU6dkYHfNpxIcrB3N1Br/k1xdh1yONNyZ+eMu9 tSAc+IvZwpPHlg==; Date: Thu, 17 Apr 2025 10:37:56 +0300 Message-Id: <86h62ndyqz.fsf@gnu.org> From: Eli Zaretskii To: Konstantin Kharlamov In-Reply-To: <10ba685f25598d5df5a496940a2a350a89040a3b.camel@yandex.ru> (message from Konstantin Kharlamov on Thu, 17 Apr 2025 10:12:43 +0300) Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727) References: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> <34D65C29-C4E5-44DE-BC8A-560381945752@gmail.com> <10ba685f25598d5df5a496940a2a350a89040a3b.camel@yandex.ru> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77727 Cc: casouri@gmail.com, 77727@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: 77727@debbugs.gnu.org > From: Konstantin Kharlamov > Date: Thu, 17 Apr 2025 10:12:43 +0300 > > On Wed, 2025-04-16 at 22:58 -0700, Yuan Fu wrote: > > > > > > > On Apr 11, 2025, at 4:51 AM, Konstantin Kharlamov > > > wrote: > > > > > > On Fri, 2025-04-11 at 11:34 +0300, Konstantin Kharlamov wrote: > > > > CC: Yuan Fu as the author of the code in question. > > > > > > > > What happens in the code makes sense: since the comment resides > > > > at > > > > top- > > > > level, the parent of any top-level statement (returned by > > > > (treesit- > > > > node-parent node)) is, well, beginning of a buffer. > > > > > > > > So the question is, why the check works that way. > > > > > > Please see the attached patch, it'd seem this is exactly the fix > > > that's > > > expected here. Basically, the problematic check is specific to Rust > > > treesitter mode, so shouldn't be executed in other languages. The > > > patch > > > factors out the entire check to a separate function and adds > > > additional > > > condition of (eq major-mode 'rust-ts-mode). > > > > > > Tested in tsx-ts-mode, it fixes the problem. > > > <1.patch> > > > > Thanks! Your analysis is correct. But I don’t want to hard-code rust- > > ts-mode in the function, since modes with other names can very well > > use rust parser. I pushed 9d43715baa5 that operates in the similar > > vein as your patch. Instead of checking for the current major mode, I > > tighten the condition by adding an additional check that ensure the > > parent node is a comment node. So now if the parent node is the root > > node (as in your initial example), the condition should fail. Please > > see if it fixes your problem. > > > > Yuan > > Well, FWIW latest master as of 2925ff6c538 doesn't even start for me: > > λ emacs -Q > Loading loadup.el (source)... > Dump mode: nil > Using load-path (/usr/share/emacs/31.0.50/lisp /usr/share/emacs/31.0.50/lisp/emacs-lisp /usr/share/emacs/31.0.50/lisp/progmodes /usr/share/emacs/31.0.50/lisp/language /usr/share/emacs/31.0.50/lisp/international /usr/share/emacs/31.0.50/lisp/textmodes /usr/share/emacs/31.0.50/lisp/vc) > Loading emacs-lisp/debug-early... > Symbol's function definition is void: file-name-sans-extension > > I tried jumping down between some commits and rebuilding, but it > doesn't go away. It looks like you invoke an installed Emacs? IOW, did you say "make install" after patching or updating from Git? And did you make sure the .pdmp pdumper file is updated by that? The above seems to indicate that Emacs cannot find the pdumper file for some reason. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 17 04:19:50 2025 Received: (at 77727) by debbugs.gnu.org; 17 Apr 2025 08:19:50 +0000 Received: from localhost ([127.0.0.1]:45700 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u5KTN-00040h-UK for submit@debbugs.gnu.org; Thu, 17 Apr 2025 04:19:50 -0400 Received: from forward500a.mail.yandex.net ([178.154.239.80]:43544) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u5KTJ-000404-HM for 77727@debbugs.gnu.org; Thu, 17 Apr 2025 04:19:47 -0400 Received: from mail-nwsmtp-smtp-production-main-74.iva.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-74.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:af90:0:640:8d90:0]) by forward500a.mail.yandex.net (Yandex) with ESMTPS id 3179C6103E; Thu, 17 Apr 2025 11:19:38 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-74.iva.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id bJE8ZqKLlmI0-8QLqMEz6; Thu, 17 Apr 2025 11:19:37 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1744877977; bh=tWlNpD+Y6hbd6mrS888WZUvQW7mW6s0mwP7ll7nnCv8=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=f0SdVQwagQz1B/3OcoHngk9YgBuj9sNMn0JlyARFgQ58C3F+cHTORUi5mwe3CexCH X1Z3FFkbmQduNLyxz/qT4x2fn63EDn/wqRvVkQmlWxr8JBHPl8mKpDLdCgLjaoKPpy H8XH0QAmlQ7cRZtFIvKllJsJPp/am2vrw3K8+QQM= Authentication-Results: mail-nwsmtp-smtp-production-main-74.iva.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727) From: Konstantin Kharlamov To: Eli Zaretskii Date: Thu, 17 Apr 2025 11:19:37 +0300 In-Reply-To: <86h62ndyqz.fsf@gnu.org> References: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> <34D65C29-C4E5-44DE-BC8A-560381945752@gmail.com> <10ba685f25598d5df5a496940a2a350a89040a3b.camel@yandex.ru> <86h62ndyqz.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.0 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77727 Cc: casouri@gmail.com, 77727@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 Thu, 2025-04-17 at 10:37 +0300, Eli Zaretskii wrote: > > Cc: 77727@debbugs.gnu.org > > From: Konstantin Kharlamov > > Date: Thu, 17 Apr 2025 10:12:43 +0300 > >=20 > > On Wed, 2025-04-16 at 22:58 -0700, Yuan Fu wrote: > > >=20 > > >=20 > > > > On Apr 11, 2025, at 4:51=E2=80=AFAM, Konstantin Kharlamov > > > > wrote: > > > >=20 > > > > On Fri, 2025-04-11 at 11:34 +0300, Konstantin Kharlamov wrote: > > > > > CC: Yuan Fu as the author of the code in question. > > > > >=20 > > > > > What happens in the code makes sense: since the comment > > > > > resides > > > > > at > > > > > top- > > > > > level, the parent of any top-level statement (returned by > > > > > (treesit- > > > > > node-parent node)) is, well, beginning of a buffer. > > > > >=20 > > > > > So the question is, why the check works that way. > > > >=20 > > > > Please see the attached patch, it'd seem this is exactly the > > > > fix > > > > that's > > > > expected here. Basically, the problematic check is specific to > > > > Rust > > > > treesitter mode, so shouldn't be executed in other languages. > > > > The > > > > patch > > > > factors out the entire check to a separate function and adds > > > > additional > > > > condition of (eq major-mode 'rust-ts-mode). > > > >=20 > > > > Tested in tsx-ts-mode, it fixes the problem. > > > > <1.patch> > > >=20 > > > Thanks! Your analysis is correct. But I don=E2=80=99t want to hard-co= de > > > rust- > > > ts-mode in the function, since modes with other names can very > > > well > > > use rust parser. I pushed 9d43715baa5 that operates in the > > > similar > > > vein as your patch. Instead of checking for the current major > > > mode, I > > > tighten the condition by adding an additional check that ensure > > > the > > > parent node is a comment node. So now if the parent node is the > > > root > > > node (as in your initial example), the condition should fail. > > > Please > > > see if it fixes your problem. > > >=20 > > > Yuan > >=20 > > Well, FWIW latest master as of 2925ff6c538 doesn't even start for > > me: > >=20 > > =C2=A0=C2=A0=C2=A0 =CE=BB emacs -Q > > =C2=A0=C2=A0=C2=A0 Loading loadup.el (source)... > > =C2=A0=C2=A0=C2=A0 Dump mode: nil > > =C2=A0=C2=A0=C2=A0 Using load-path (/usr/share/emacs/31.0.50/lisp > > /usr/share/emacs/31.0.50/lisp/emacs-lisp > > /usr/share/emacs/31.0.50/lisp/progmodes > > /usr/share/emacs/31.0.50/lisp/language > > /usr/share/emacs/31.0.50/lisp/international > > /usr/share/emacs/31.0.50/lisp/textmodes > > /usr/share/emacs/31.0.50/lisp/vc) > > =C2=A0=C2=A0=C2=A0 Loading emacs-lisp/debug-early... > > =C2=A0=C2=A0=C2=A0 Symbol's function definition is void: file-name-sans= -extension > >=20 > > I tried jumping down between some commits and rebuilding, but it > > doesn't go away. >=20 > It looks like you invoke an installed Emacs?=C2=A0 IOW, did you say "make > install" after patching or updating from Git?=C2=A0 And did you make sure > the .pdmp pdumper file is updated by that?=C2=A0 The above seems to > indicate that Emacs cannot find the pdumper file for some reason. Yep, it's an installed Emacs. I am not sure what do you mean by `.pdmp` file, I never touched them. I see the resulting package has file /usr/lib/emacs/31.0.50/x86_64-pc- linux-gnu/emacs- 8dc71cdb3ec816249f8467e350dff31faabf46305805586b479fc8f3412dbdbb.pdmp, am I supposed to do something about it=E2=80=A6? I looked through PKGBUILD = (a popular script used to assemble emacs from git as an Archlinux package), and there's no mention of pdmp, so=E2=80=A6 Neither me, nor the script ever touched this file, well, not directly at least. Before I wrote this email I also tried doing a `make bootstrap` to make sure there's no older artifacts that could cause it, but resulting Emacs still produces same errors. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 17 06:53:57 2025 Received: (at 77727) by debbugs.gnu.org; 17 Apr 2025 10:53:57 +0000 Received: from localhost ([127.0.0.1]:45949 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u5MsW-0003QO-PG for submit@debbugs.gnu.org; Thu, 17 Apr 2025 06:53:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49110) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u5MsU-0003Q0-Eg for 77727@debbugs.gnu.org; Thu, 17 Apr 2025 06:53:55 -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 1u5MsO-0003QD-4e; Thu, 17 Apr 2025 06:53:48 -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=c30IktDwrbxSS3FCTq91X8x+2aGcdW1/Gmkha2ijkBg=; b=TkbqSbXEMTultRH313UK pMTwQDm3LmKCbvZOtIDQ3upzz4WZ31kAqfpfkd0hM1n3XmY0hlUYaMtuMCopL03cZIfXtmPVcB+mO q9murU0J3aYD08iCu/W6rV7XSfPYoQVNBRERdT4/fzwh0p2v4/VqugXR2ggpQlCnYEb6A1uM+Uy5R 9FBP0HI5J1T4/9lxNgDy7fQgXwbBTPc35oYsfI8DzmWyMKuejgPWHcZNZInZdgbWJqD9htECVKAFe kl6c78xifW9yQVCC7LwFIhMpZnJqgNLc6KB8An/JgymaTJV1l90y2HvuuuIQK8iyx1mrcyg++lnO0 OVoKX8LDvFOibg==; Date: Thu, 17 Apr 2025 13:53:42 +0300 Message-Id: <86fri7dpop.fsf@gnu.org> From: Eli Zaretskii To: Konstantin Kharlamov In-Reply-To: (message from Konstantin Kharlamov on Thu, 17 Apr 2025 11:19:37 +0300) Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727) References: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> <34D65C29-C4E5-44DE-BC8A-560381945752@gmail.com> <10ba685f25598d5df5a496940a2a350a89040a3b.camel@yandex.ru> <86h62ndyqz.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: 77727 Cc: casouri@gmail.com, 77727@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: Konstantin Kharlamov > Cc: casouri@gmail.com, 77727@debbugs.gnu.org > Date: Thu, 17 Apr 2025 11:19:37 +0300 > > On Thu, 2025-04-17 at 10:37 +0300, Eli Zaretskii wrote: > > >     λ emacs -Q > > >     Loading loadup.el (source)... > > >     Dump mode: nil > > >     Using load-path (/usr/share/emacs/31.0.50/lisp > > > /usr/share/emacs/31.0.50/lisp/emacs-lisp > > > /usr/share/emacs/31.0.50/lisp/progmodes > > > /usr/share/emacs/31.0.50/lisp/language > > > /usr/share/emacs/31.0.50/lisp/international > > > /usr/share/emacs/31.0.50/lisp/textmodes > > > /usr/share/emacs/31.0.50/lisp/vc) > > >     Loading emacs-lisp/debug-early... > > >     Symbol's function definition is void: file-name-sans-extension > > > > > > I tried jumping down between some commits and rebuilding, but it > > > doesn't go away. > > > > It looks like you invoke an installed Emacs?  IOW, did you say "make > > install" after patching or updating from Git?  And did you make sure > > the .pdmp pdumper file is updated by that?  The above seems to > > indicate that Emacs cannot find the pdumper file for some reason. > > Yep, it's an installed Emacs. > > I am not sure what do you mean by `.pdmp` file, I never touched them. Rebuilding Emacs produces a new .pdmp file, which the previous binary will not load (because it doesn't fit it). When you rebuild Emacs, you need to invoke "make install" afterwards, to install the Emacs binary and the auxiliary files, including the new .pdmp file, in the place where Emacs expects to find it. Did you run "make install" after rebuilding? > I > see the resulting package has file /usr/lib/emacs/31.0.50/x86_64-pc- > linux-gnu/emacs- > 8dc71cdb3ec816249f8467e350dff31faabf46305805586b479fc8f3412dbdbb.pdmp, > am I supposed to do something about it…? I looked through PKGBUILD (a > popular script used to assemble emacs from git as an Archlinux > package), and there's no mention of pdmp, so… Neither me, nor the > script ever touched this file, well, not directly at least. "make install" does what needs to be done with the .pdmp file: copies it to the correct directory under the correct name. > Before I wrote this email I also tried doing a `make bootstrap` to make > sure there's no older artifacts that could cause it, but resulting > Emacs still produces same errors. If you run Emacs from the src directory of the build tree, does it work? From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 17 07:10:09 2025 Received: (at 77727) by debbugs.gnu.org; 17 Apr 2025 11:10:09 +0000 Received: from localhost ([127.0.0.1]:45967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u5N8B-0005Xs-TM for submit@debbugs.gnu.org; Thu, 17 Apr 2025 07:10:09 -0400 Received: from forward501b.mail.yandex.net ([2a02:6b8:c02:900:1:45:d181:d501]:32896) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u5N86-0005UM-6z for 77727@debbugs.gnu.org; Thu, 17 Apr 2025 07:10:05 -0400 Received: from mail-nwsmtp-smtp-production-main-98.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-98.sas.yp-c.yandex.net [IPv6:2a02:6b8:c16:123:0:640:744c:0]) by forward501b.mail.yandex.net (Yandex) with ESMTPS id E60D1614C1; Thu, 17 Apr 2025 14:09:55 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-98.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id s9HFMUZLZqM0-o2mzWmdQ; Thu, 17 Apr 2025 14:09:55 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1744888195; bh=/yJaUk/DTMniC0rZAnenoYEzv2IQXbXmSP0Uw1HBUbA=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=OQEjWNIU3l7rVwd525+FU+uFIlpHFI77XOS5FNe4xkIB5ThlNogDCeILl/7/OZF7u 8aXCrfjBMDWjVkH/4E5sZtRKDnLjS0kGN013O0ly39Nd4/FzkGwHgh76wV/yDKuAQ9 8GunPOoXZSh7rHXYX6P0M9qXyUoBhHp1a5Nnziwg= Authentication-Results: mail-nwsmtp-smtp-production-main-98.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <53ed8a1ed71213f952cc23b6ac5bd95bba2aa9da.camel@yandex.ru> Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727) From: Konstantin Kharlamov To: Eli Zaretskii Date: Thu, 17 Apr 2025 14:09:54 +0300 In-Reply-To: <86fri7dpop.fsf@gnu.org> References: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> <34D65C29-C4E5-44DE-BC8A-560381945752@gmail.com> <10ba685f25598d5df5a496940a2a350a89040a3b.camel@yandex.ru> <86h62ndyqz.fsf@gnu.org> <86fri7dpop.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.0 MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 77727 Cc: casouri@gmail.com, 77727@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 Thu, 2025-04-17 at 13:53 +0300, Eli Zaretskii wrote: > > From: Konstantin Kharlamov > > Cc: casouri@gmail.com, 77727@debbugs.gnu.org > > Date: Thu, 17 Apr 2025 11:19:37 +0300 > >=20 > > On Thu, 2025-04-17 at 10:37 +0300, Eli Zaretskii wrote: > > > > =C2=A0=C2=A0=C2=A0 =CE=BB emacs -Q > > > > =C2=A0=C2=A0=C2=A0 Loading loadup.el (source)... > > > > =C2=A0=C2=A0=C2=A0 Dump mode: nil > > > > =C2=A0=C2=A0=C2=A0 Using load-path (/usr/share/emacs/31.0.50/lisp > > > > /usr/share/emacs/31.0.50/lisp/emacs-lisp > > > > /usr/share/emacs/31.0.50/lisp/progmodes > > > > /usr/share/emacs/31.0.50/lisp/language > > > > /usr/share/emacs/31.0.50/lisp/international > > > > /usr/share/emacs/31.0.50/lisp/textmodes > > > > /usr/share/emacs/31.0.50/lisp/vc) > > > > =C2=A0=C2=A0=C2=A0 Loading emacs-lisp/debug-early... > > > > =C2=A0=C2=A0=C2=A0 Symbol's function definition is void: file-name-= sans- > > > > extension > > > >=20 > > > > I tried jumping down between some commits and rebuilding, but > > > > it > > > > doesn't go away. > > >=20 > > > It looks like you invoke an installed Emacs?=C2=A0 IOW, did you say > > > "make > > > install" after patching or updating from Git?=C2=A0 And did you make > > > sure > > > the .pdmp pdumper file is updated by that?=C2=A0 The above seems to > > > indicate that Emacs cannot find the pdumper file for some reason. > >=20 > > Yep, it's an installed Emacs. > >=20 > > I am not sure what do you mean by `.pdmp` file, I never touched > > them. >=20 > Rebuilding Emacs produces a new .pdmp file, which the previous binary > will not load (because it doesn't fit it).=C2=A0 When you rebuild Emacs, > you need to invoke "make install" afterwards, to install the Emacs > binary and the auxiliary files, including the new .pdmp file, in the > place where Emacs expects to find it.=C2=A0 Did you run "make install" > after rebuilding? Yes, it's being run as `make DESTDIR=3D"$pkgdir/" install` > > I > > see the resulting package has file /usr/lib/emacs/31.0.50/x86_64- > > pc- > > linux-gnu/emacs- > > 8dc71cdb3ec816249f8467e350dff31faabf46305805586b479fc8f3412dbdbb.pd > > mp, > > am I supposed to do something about it=E2=80=A6? I looked through PKGBU= ILD > > (a > > popular script used to assemble emacs from git as an Archlinux > > package), and there's no mention of pdmp, so=E2=80=A6 Neither me, nor t= he > > script ever touched this file, well, not directly at least. >=20 > "make install" does what needs to be done with the .pdmp file: copies > it to the correct directory under the correct name. Okay, so I just tried doing a `find -type f -name "*.pdmp" -delete`, and then rebuilding Emacs (to make sure no pdmp files are stale), then assembled/installed package. I see the file ends up is at /usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs- e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp This is same location as for the "working" Emacs build: /usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs- 37634abbce82a9c44ab59298a6ed926eb3396ac970e12cc2c2798d93deb8eee8.pdmp > > Before I wrote this email I also tried doing a `make bootstrap` to > > make > > sure there's no older artifacts that could cause it, but resulting > > Emacs still produces same errors. >=20 > If you run Emacs from the src directory of the build tree, does it > work? Yes, if I run it as `./build/src/emacs -Q`, it does work. So apparently it's something to do with installation=E2=80=A6 But I'm not doing anything = odd, it's plain old `make install` with DESTDIR set, used it for years=E2=80=A6 From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 17 09:12:29 2025 Received: (at 77727) by debbugs.gnu.org; 17 Apr 2025 13:12:30 +0000 Received: from localhost ([127.0.0.1]:46207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u5P2a-0005gP-H1 for submit@debbugs.gnu.org; Thu, 17 Apr 2025 09:12:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46186) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u5P2V-0005fW-Ms for 77727@debbugs.gnu.org; Thu, 17 Apr 2025 09:12:25 -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 1u5P2Q-00089R-7K; Thu, 17 Apr 2025 09:12: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=hEQVcy9BcWeVjBi9wiyxL/9JH1U3KpU8bCJvumV2WeY=; b=G66FpnFELdX7vQZE/7f4 76spWjJ5an29CNK6yINEHjGFINDxSuJFxzHJ7GadrUNNfUI/34pYr1B1VWquqmhB46y/572V9Wsv2 7UMzcDx3tGE2Ci41ft1+ljKhh2XJHWmDFtb4F+Fk3Odpxl6VsycO2JN4gyMc4+rfahE8gLrxg59Ub pfAmIFtljK0obB52FMBnAupeqqy/dJBgeipSpOHwb6mGKmROkJG6QYj+j/55roU7F6hSSJ3VecQRy z+rICBq4rNsXVFip4mUoue5QzrmC4gQoQkZPN1EOUkOnRPG/aPcTa/GmM9NN/+Xuz+v/0UeIuZD5X WVEg9sDJRAXe+A==; Date: Thu, 17 Apr 2025 16:12:14 +0300 Message-Id: <86bjsvdj9t.fsf@gnu.org> From: Eli Zaretskii To: Konstantin Kharlamov In-Reply-To: <53ed8a1ed71213f952cc23b6ac5bd95bba2aa9da.camel@yandex.ru> (message from Konstantin Kharlamov on Thu, 17 Apr 2025 14:09:54 +0300) Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727) References: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> <34D65C29-C4E5-44DE-BC8A-560381945752@gmail.com> <10ba685f25598d5df5a496940a2a350a89040a3b.camel@yandex.ru> <86h62ndyqz.fsf@gnu.org> <86fri7dpop.fsf@gnu.org> <53ed8a1ed71213f952cc23b6ac5bd95bba2aa9da.camel@yandex.ru> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77727 Cc: casouri@gmail.com, 77727@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: Konstantin Kharlamov > Cc: casouri@gmail.com, 77727@debbugs.gnu.org > Date: Thu, 17 Apr 2025 14:09:54 +0300 > > > Rebuilding Emacs produces a new .pdmp file, which the previous binary > > will not load (because it doesn't fit it).  When you rebuild Emacs, > > you need to invoke "make install" afterwards, to install the Emacs > > binary and the auxiliary files, including the new .pdmp file, in the > > place where Emacs expects to find it.  Did you run "make install" > > after rebuilding? > > Yes, it's being run as `make DESTDIR="$pkgdir/" install` What is the value of $pkgdir ? > Okay, so I just tried doing a `find -type f -name "*.pdmp" -delete`, > and then rebuilding Emacs (to make sure no pdmp files are stale), then > assembled/installed package. I see the file ends up is at > > /usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs- > e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp When you build Emacs, it shows the fingerprint, like this: Dumping under the name emacs.pdmp Dumping fingerprint: 189095568e4fae77c858f1c5071e36beaf86dbf632e161df634a1099dc31f876 Dump complete Is the fingerprint in your case identical to the name of the .pdmp file (sans the extension)? If it is identical, are you sure you are invoking the correct 'emacs' executable? How many Emacs executables do you have in the $pkgdir/bin directory (from where you supposedly invoke Emacs), and what are their names? > This is same location as for the "working" Emacs build: What is the "working" Emacs build, and how is it different from the one that doesn't work? > > If you run Emacs from the src directory of the build tree, does it > > work? > > Yes, if I run it as `./build/src/emacs -Q`, it does work. Is the contents of the emacs.pdmp file in the source directory identical to the contents of /usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs-e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp? From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 17 14:12:37 2025 Received: (at 77727) by debbugs.gnu.org; 17 Apr 2025 18:12:38 +0000 Received: from localhost ([127.0.0.1]:48327 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u5Tj0-0000Vo-N8 for submit@debbugs.gnu.org; Thu, 17 Apr 2025 14:12:37 -0400 Received: from forward500b.mail.yandex.net ([2a02:6b8:c02:900:1:45:d181:d500]:40834) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u5Tiu-0000TY-J1 for 77727@debbugs.gnu.org; Thu, 17 Apr 2025 14:12:32 -0400 Received: from mail-nwsmtp-smtp-production-canary-88.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-canary-88.sas.yp-c.yandex.net [IPv6:2a02:6b8:c28:7d5:0:640:285a:0]) by forward500b.mail.yandex.net (Yandex) with ESMTPS id 2BA4A60FD1; Thu, 17 Apr 2025 21:12:21 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-canary-88.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id JCOTre0LaqM0-I3rgUQ15; Thu, 17 Apr 2025 21:12:20 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1744913540; bh=aEhcOTZBNZEKApJej412zaGwiOaI5sfaPkICr1XYjfI=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=ICTh+gR62EHK60sdRaU85bOIxobGEDLGuqOw7M0hm5BPL/dzhEKgyXrPuA6W1DW1a FiiuWu26MgDdtEirVgpteN+kAci+6tY8JYQ/1OScAk8afjwaoomGcJ44FybmTzdIMN U/FyGOdabxCGOtmpHA5lGj5wRJvYyjK3lTO7XSNc= Authentication-Results: mail-nwsmtp-smtp-production-canary-88.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <95423b7555aea0f2fe5dd3aa856dc5b1871d3f7b.camel@yandex.ru> Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727) From: Konstantin Kharlamov To: Eli Zaretskii Date: Thu, 17 Apr 2025 21:12:19 +0300 In-Reply-To: <86bjsvdj9t.fsf@gnu.org> References: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> <34D65C29-C4E5-44DE-BC8A-560381945752@gmail.com> <10ba685f25598d5df5a496940a2a350a89040a3b.camel@yandex.ru> <86h62ndyqz.fsf@gnu.org> <86fri7dpop.fsf@gnu.org> <53ed8a1ed71213f952cc23b6ac5bd95bba2aa9da.camel@yandex.ru> <86bjsvdj9t.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.0 MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 77727 Cc: casouri@gmail.com, 77727@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.7 (-) On Thu, 2025-04-17 at 16:12 +0300, Eli Zaretskii wrote: > > From: Konstantin Kharlamov > > Cc: casouri@gmail.com, 77727@debbugs.gnu.org > > Date: Thu, 17 Apr 2025 14:09:54 +0300 > > > > > Rebuilding Emacs produces a new .pdmp file, which the previous > > > binary > > > will not load (because it doesn't fit it).=C2=A0 When you rebuild > > > Emacs, > > > you need to invoke "make install" afterwards, to install the > > > Emacs > > > binary and the auxiliary files, including the new .pdmp file, in > > > the > > > place where Emacs expects to find it.=C2=A0 Did you run "make install= " > > > after rebuilding? > > > > Yes, it's being run as `make DESTDIR=3D"$pkgdir/" install` > > What is the value of $pkgdir ? It's /home/constantine/Projects/builds/emacs-git/pkg/emacs-git/ > > Okay, so I just tried doing a `find -type f -name "*.pdmp" - > > delete`, > > and then rebuilding Emacs (to make sure no pdmp files are stale), > > then > > assembled/installed package. I see the file ends up is at > > > > /usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs- > > e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pd > > mp > > When you build Emacs, it shows the fingerprint, like this: > > =C2=A0 Dumping under the name emacs.pdmp > =C2=A0 Dumping fingerprint: > 189095568e4fae77c858f1c5071e36beaf86dbf632e161df634a1099dc31f876 > =C2=A0 Dump complete > > Is the fingerprint in your case identical to the name of the .pdmp > file (sans the extension)? Yes. I just rebuilt while saving the output, and there are 3 fingerprints mentioning lines: Dumping fingerprint: e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125= fbfd437df5 Dumping fingerprint: e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125= fbfd437df5 /usr/bin/install -c -m 644 src/emacs.pdmp "/home/constantine/Projects/build= s/emacs-git/pkg/emacs-git//usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu"/emacs= -`./src/emacs --fingerprint`.pdmp It is the file that ends up installed: /usr/lib/emacs/31.0.50/x86_64- pc-linux-gnu/emacs- e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp. > If it is identical, are you sure you are invoking the correct 'emacs' > executable? I am invoking Emacs globally, i.e. just `emacs`. I install newly built Emacs, then I try calling `emacs -Q`, I get the error, and then I install the older Emacs build I was using previously and which works. > =C2=A0 How many Emacs executables do you have in the $pkgdir/bin > directory (from where you supposedly invoke Emacs), and what are > their names? =CE=BB ls ./pkg/emacs-git/usr/bin/ ebrowse emacs emacs-31.0.50 emacsclient etags.emacs nemacs =CE=BB pacman -Ql emacs-git | grep usr/bin/ emacs-git /usr/bin/ emacs-git /usr/bin/ebrowse emacs-git /usr/bin/emacs emacs-git /usr/bin/emacs-31.0.50 emacs-git /usr/bin/emacsclient emacs-git /usr/bin/etags.emacs emacs-git /usr/bin/nemacs Btw, since you asked, I also just of thought of trying to invoke `./pkg/emacs-git/usr/bin/emacs -Q` rather than the global emacs. It ends up printing same output. > > This is same location as for the "working" Emacs build: > > What is the "working" Emacs build, and how is it different from the > one that doesn't work? They're just assembled from different commits, I looked at the files list and it's the same, barring the difference in hash names in some files. Actually, it turns out that assembling from the older commit fails as well now. I will try tomorrow to remove whole build directory completely and re-clone everything from scratch. > > > If you run Emacs from the src directory of the build tree, does > > > it > > > work? > > > > Yes, if I run it as `./build/src/emacs -Q`, it does work. > > Is the contents of the emacs.pdmp file in the source directory > identical to the contents of > /usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs- > e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp > ? Yes: =CE=BB md5sum ./pkg/emacs-git/usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu= /emacs-e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdm= p /usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs-e58067db04d41ca123ffe4dd= c2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp 36511c7936b906a2f8719e9eea6401c2 ./pkg/emacs-git/usr/lib/emacs/31.0.50= /x86_64-pc-linux-gnu/emacs-e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87= b01125fbfd437df5.pdmp 36511c7936b906a2f8719e9eea6401c2 /usr/lib/emacs/31.0.50/x86_64-pc-linu= x-gnu/emacs-e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df= 5.pdmp From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 18 01:58:05 2025 Received: (at 77727) by debbugs.gnu.org; 18 Apr 2025 05:58:05 +0000 Received: from localhost ([127.0.0.1]:49365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u5ejk-0001nS-Bf for submit@debbugs.gnu.org; Fri, 18 Apr 2025 01:58:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32876) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u5ejd-0001l2-LZ for 77727@debbugs.gnu.org; Fri, 18 Apr 2025 01:58:01 -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 1u5ejX-0008GY-FE; Fri, 18 Apr 2025 01:57:51 -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=mLis3FyPTEV9wGI8/L5ByLKkvk5EU+R0RM2BZMwGJL4=; b=RBFnYSrV2IA/Oyrrq1mG a6RONzEinLMxzD/LTKzyI+Ekn0sW87W/LUKjp4uD1YYynB2vgy7wBzIu+T85uEoZpyylzrljcGQO7 J7/cKeDoOIySFOzYMHqBnBmSXeG2Av9g1aTvdSLUt+UJ3UifUCRjYjD0wwzH5XUVlHv50I9p7PVIo hujLBDYTUGpM1AT2cbkN81PRR2TTX9cUCBOg68nk2jh3dLJtlLKg37ee+RqRy5cXyvcfgCdLr3KE8 EX96THdO/9sfUqqr1kE4XLGTkRGF6owR3JNvav0kVn23zH1X7jnUF7oHWOzDzE6nuiU5XlZSKWIoH izqXAKAYXEt6YQ==; Date: Fri, 18 Apr 2025 08:57:41 +0300 Message-Id: <86y0vyau5m.fsf@gnu.org> From: Eli Zaretskii To: Konstantin Kharlamov In-Reply-To: <95423b7555aea0f2fe5dd3aa856dc5b1871d3f7b.camel@yandex.ru> (message from Konstantin Kharlamov on Thu, 17 Apr 2025 21:12:19 +0300) Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727) References: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> <34D65C29-C4E5-44DE-BC8A-560381945752@gmail.com> <10ba685f25598d5df5a496940a2a350a89040a3b.camel@yandex.ru> <86h62ndyqz.fsf@gnu.org> <86fri7dpop.fsf@gnu.org> <53ed8a1ed71213f952cc23b6ac5bd95bba2aa9da.camel@yandex.ru> <86bjsvdj9t.fsf@gnu.org> <95423b7555aea0f2fe5dd3aa856dc5b1871d3f7b.camel@yandex.ru> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77727 Cc: casouri@gmail.com, 77727@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: Konstantin Kharlamov > Cc: casouri@gmail.com, 77727@debbugs.gnu.org > Date: Thu, 17 Apr 2025 21:12:19 +0300 > > > > Yes, it's being run as `make DESTDIR="$pkgdir/" install` > > > > What is the value of $pkgdir ? > > It's /home/constantine/Projects/builds/emacs-git/pkg/emacs-git/ If that's so, then why is the .pdmp file installed under /usr/lib/ and not under $pkgdir? You said: > > > Okay, so I just tried doing a `find -type f -name "*.pdmp" - > > > delete`, > > > and then rebuilding Emacs (to make sure no pdmp files are stale), > > > then > > > assembled/installed package. I see the file ends up is at > > > > > > /usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu/emacs- > > > e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pd > > > mp This is not under $pkgdir. And the /usr/lib/ part is incorrect: it should be under libexec/ instead. Or did you configure $libexecdir to be in /usr/lib/ for some reason? (That's not the default.) Do you have a directory named like this: /home/constantine/Projects/builds/emacs-git/pkg/emacs-git/usr/libexec/emacs/31.0.50/x86_64-pc-linux-gnu/ and if you do, do you see a .pdmp file of the above name there? > > Is the fingerprint in your case identical to the name of the .pdmp > > file (sans the extension)? > > Yes. I just rebuilt while saving the output, and there are 3 > fingerprints mentioning lines: > > Dumping fingerprint: e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5 > Dumping fingerprint: e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5 > /usr/bin/install -c -m 644 src/emacs.pdmp "/home/constantine/Projects/builds/emacs-git/pkg/emacs-git//usr/lib/emacs/31.0.50/x86_64-pc-linux-gnu"/emacs-`./src/emacs --fingerprint`.pdmp > > It is the file that ends up installed: /usr/lib/emacs/31.0.50/x86_64- > pc-linux-gnu/emacs- > e58067db04d41ca123ffe4ddc2ed9d0ebdef685b08d89c87b01125fbfd437df5.pdmp. But note that the directory is incorrect: the "/usr/bin/install -c" command correctly installs under $pkgdir, not in /usr/lib/emacs/. > >   How many Emacs executables do you have in the $pkgdir/bin > > directory (from where you supposedly invoke Emacs), and what are > > their names? > > λ ls ./pkg/emacs-git/usr/bin/ > ebrowse emacs emacs-31.0.50 emacsclient etags.emacs nemacs > λ pacman -Ql emacs-git | grep usr/bin/ > emacs-git /usr/bin/ > emacs-git /usr/bin/ebrowse > emacs-git /usr/bin/emacs > emacs-git /usr/bin/emacs-31.0.50 > emacs-git /usr/bin/emacsclient > emacs-git /usr/bin/etags.emacs > emacs-git /usr/bin/nemacs What does "ls -l" say about those executables? > Btw, since you asked, I also just of thought of trying to invoke > `./pkg/emacs-git/usr/bin/emacs -Q` rather than the global emacs. It ends up > printing same output. Anyway, I don't quite understand what happens (too many custom scripts and variables are involved), but it looks like you have a botched configuration of how Emacs is installed for some reason. You need to sort that out, I think. I believe others are using installed Emacs 31 with no problems, so it's something local on your system. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 18 05:48:18 2025 Received: (at 77727) by debbugs.gnu.org; 18 Apr 2025 09:48:18 +0000 Received: from localhost ([127.0.0.1]:49735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u5iKW-0001gi-VR for submit@debbugs.gnu.org; Fri, 18 Apr 2025 05:48:18 -0400 Received: from forward501a.mail.yandex.net ([178.154.239.81]:39836) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u5iKT-0001fH-Rl for 77727@debbugs.gnu.org; Fri, 18 Apr 2025 05:48:15 -0400 Received: from mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net [IPv6:2a02:6b8:c1f:1a98:0:640:f7e1:0]) by forward501a.mail.yandex.net (Yandex) with ESMTPS id 912F860B02; Fri, 18 Apr 2025 12:48:04 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id 3mGCOJGLjKo0-jvvXyTpI; Fri, 18 Apr 2025 12:48:04 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1744969684; bh=Puartii/alBigTk1tCrTBn2N7KUExFCLzS75tFx9+cU=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=DyURl2Ym8URrUs7SrmTu8MGEsZgym/oAID5HVmZMKCG0Za+xk0Nwp1m4jBKwxQiuV h4kx8HlAe2WohD+bii1l4YJFJUbW6GekJJN63NDNQoFrYWHl5rjBlFKRPlwsXpoLQv UttOaKH7wx+uH4ZmjPZYM0eDq7ead8RIzKzGw7vU= Authentication-Results: mail-nwsmtp-smtp-production-main-74.vla.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <2d2d7e4cea0f335061a74bf9c5f83ab35eddf466.camel@yandex.ru> Subject: Re: bug#77727: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727) From: Konstantin Kharlamov To: Eli Zaretskii Date: Fri, 18 Apr 2025 12:48:03 +0300 In-Reply-To: <86y0vyau5m.fsf@gnu.org> References: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> <34D65C29-C4E5-44DE-BC8A-560381945752@gmail.com> <10ba685f25598d5df5a496940a2a350a89040a3b.camel@yandex.ru> <86h62ndyqz.fsf@gnu.org> <86fri7dpop.fsf@gnu.org> <53ed8a1ed71213f952cc23b6ac5bd95bba2aa9da.camel@yandex.ru> <86bjsvdj9t.fsf@gnu.org> <95423b7555aea0f2fe5dd3aa856dc5b1871d3f7b.camel@yandex.ru> <86y0vyau5m.fsf@gnu.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.0 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77727 Cc: casouri@gmail.com, 77727@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 (-) Anyway, to avoid keep guessing I did a series of experiments. I first found that recloning everything anew fixes the problem. I kept the older problematic repo, so at that point I tried: 1. Removing `build` dir 2. Removing everything untracked under `lisp/` (with `git clean -fdx -- lisp`). 3. Removing the DESTDIR, i.e. recreating it anew before installation. Neither helped. At that point I tried a `git clean -fdx -- .` to remove everything untracked from Emacs repo. That did help. So at that point it is clear the reason for the break is some stray artifact not being removed, not even by `make boostrap`. I created a list of files before and after (with `git status --ignored`), and the difference is only the removed files (no added ones) as shown below. I don't really see how any of them could be causing it, but=E2=80=A6 well, these are the findings. 15d13 < Makefile 17d14 < admin/charsets/Makefile 20,21d16 < admin/grammars/Makefile < admin/unidata/Makefile 192,193d186 < config.log < config.status 195,197d187 < configure~ < cross/Makefile < doc/emacs/Makefile 199,200d188 < doc/lispintro/Makefile < doc/lispref/Makefile 202d189 < doc/misc/Makefile 341d327 < exec/config.h.in~ 344d329 < exec/configure~ 347,353d331 < java/AndroidManifest.xml < java/Makefile < leim/Makefile < leim/small-ja-dic-option < lib-src/Makefile < lib/Makefile < lib/gnulib.mk 2055,2060d2032 < lwlib/Makefile < nextstep/Makefile < nt/Makefile < oldXMenu/Makefile < src/Makefile < src/config.h 2062,2068d2033 < src/config.in~ < src/emacs-module.h < src/epaths.h < src/verbose.mk < test/Makefile < test/infra/Makefile < test/manual/noverlay/Makefile --------- To answer your question: `./configure` call I'm using does modify some installation directories, but I'm sure it's unrelated to the problem, because these "modifications" worked before and work now that I removed build artifacts. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 18 05:48:45 2025 Received: (at 77727) by debbugs.gnu.org; 18 Apr 2025 09:48:45 +0000 Received: from localhost ([127.0.0.1]:49738 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u5iKy-0001ko-A6 for submit@debbugs.gnu.org; Fri, 18 Apr 2025 05:48:45 -0400 Received: from forward501b.mail.yandex.net ([2a02:6b8:c02:900:1:45:d181:d501]:40262) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u5iKq-0001ia-CT for 77727@debbugs.gnu.org; Fri, 18 Apr 2025 05:48:39 -0400 Received: from mail-nwsmtp-smtp-production-main-60.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-60.sas.yp-c.yandex.net [IPv6:2a02:6b8:c11:109b:0:640:c015:0]) by forward501b.mail.yandex.net (Yandex) with ESMTPS id AC91D61100; Fri, 18 Apr 2025 12:48:28 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-60.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id RmG8DqoLauQ0-9CcLpJKZ; Fri, 18 Apr 2025 12:48:28 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1744969708; bh=PcIWOtywCLLPTlobALNS6WrBY5JFv9PDCqYiIlWpK1M=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=HQcbu4ibVhL+dOXCQhXFX26bmsJmyOEgphgxF3wemhGZrSMZunhu2oeGaDsap2wMj jdIQ5lqHHnY79SS39h8obG18ehus40DncVQ3a/zC/YE4i0vAtC+fFAoOSf1+AE51dg h3Y+H3sZYkR9IxeZIo8G2GAEJkdhfBMDhvpG9fyg= Authentication-Results: mail-nwsmtp-smtp-production-main-60.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: Subject: Re: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727) From: Konstantin Kharlamov To: Yuan Fu Date: Fri, 18 Apr 2025 12:48:27 +0300 In-Reply-To: <34D65C29-C4E5-44DE-BC8A-560381945752@gmail.com> References: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> <34D65C29-C4E5-44DE-BC8A-560381945752@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.0 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77727 Cc: 77727@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 Wed, 2025-04-16 at 22:58 -0700, Yuan Fu wrote: >=20 >=20 > > On Apr 11, 2025, at 4:51=E2=80=AFAM, Konstantin Kharlamov > > wrote: > >=20 > > On Fri, 2025-04-11 at 11:34 +0300, Konstantin Kharlamov wrote: > > > CC: Yuan Fu as the author of the code in question. > > >=20 > > > What happens in the code makes sense: since the comment resides > > > at > > > top- > > > level, the parent of any top-level statement (returned by > > > (treesit- > > > node-parent node)) is, well, beginning of a buffer. > > >=20 > > > So the question is, why the check works that way. > >=20 > > Please see the attached patch, it'd seem this is exactly the fix > > that's > > expected here. Basically, the problematic check is specific to Rust > > treesitter mode, so shouldn't be executed in other languages. The > > patch > > factors out the entire check to a separate function and adds > > additional > > condition of (eq major-mode 'rust-ts-mode). > >=20 > > Tested in tsx-ts-mode, it fixes the problem. > > <1.patch> >=20 > Thanks! Your analysis is correct. But I don=E2=80=99t want to hard-code r= ust- > ts-mode in the function, since modes with other names can very well > use rust parser. I pushed 9d43715baa5 that operates in the similar > vein as your patch. Instead of checking for the current major mode, I > tighten the condition by adding an additional check that ensure the > parent node is a comment node. So now if the parent node is the root > node (as in your initial example), the condition should fail. Please > see if it fixes your problem. >=20 > Yuan Thank you, I confirm the problem is fixed, so bug can be closed. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 18 19:35:38 2025 Received: (at 77727-done) by debbugs.gnu.org; 18 Apr 2025 23:35:39 +0000 Received: from localhost ([127.0.0.1]:53262 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u5vF9-0000xv-SQ for submit@debbugs.gnu.org; Fri, 18 Apr 2025 19:35:38 -0400 Received: from mail-pf1-x42f.google.com ([2607:f8b0:4864:20::42f]:60728) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u5vF4-0000w4-Rc for 77727-done@debbugs.gnu.org; Fri, 18 Apr 2025 19:35:33 -0400 Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-7369ce5d323so1926037b3a.1 for <77727-done@debbugs.gnu.org>; Fri, 18 Apr 2025 16:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745019325; x=1745624125; 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=k22UeYjTq/eDpWEzPF+Z/qQAYAntsHK2saVnSBPRzxY=; b=a1s1S/7HSqgU/axUbNzg+wsPPoXSR0ovLxEh/znDfzi557lO3WueqDgnEd4tutGmvC 6MzYPPNXWPmjyqDFfwoj01UVszO5wxG3b83J7vpAN2TS6yfoPgtnLvamHDEfQnxQeW3V lUNQhuw1z2rYHmRRo/nf9KNBkpxTa07uBw7SZKa67JYgEMU+sm206JQGwCDjxn8vjK3r TeG2T06cjWTEgUbDKmmuBXVmTi3b8IXYM80IlQwhNucVOjqurQ5sdpUc7tGau0EOiYls wJybpGh9viJMPOfbySsps7wciBB3zVXR0QBAsJ9J7OfR8+EAIPrdW6ITGa7Bhx15W5wT BxWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745019325; x=1745624125; 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=k22UeYjTq/eDpWEzPF+Z/qQAYAntsHK2saVnSBPRzxY=; b=AdaNnfZDH0p3K4E43lWbh10q/BWuotRcFTvDpgbbuspn8hMut2qxVUGdSSjWP003Cf DCPEmGTeu0XVip024bGti+Plwsfw9q+QlQtLqXv2e4RtOFNmgI05kDNm1yBMqkJemnzD lDAa2FpOxI6qOQ7hzgbhSNDbdt7W3sSIJbkMgcrJ6Fdc4/xLrjdP5gplIz5ggO5/DOFY Mh0b58IOb3vVk4Mg6/+XviPDDexcYkUAhxhmFQAtTfjRfsyBYMFP1o6gA6qw/lFs9GFp USSij2gS/+LRILzwblj/1e5UBT3wo0aiCKP64pCd8eI0Ei/hHFUl/0mFqTlzzSHFqbYs 36Vg== X-Gm-Message-State: AOJu0YwfxUBC001Vqsv7MMg2aa5oYyZ1Q2ygbsp0189CS6u/yRHwNnTJ u8yaDrcasq9+q39SZXrmh+11V4QZDi9CMMd5NOnJAe2Xra18GhGqKrArXQ== X-Gm-Gg: ASbGnctqqMo5U1zV7hGptlShC6QFmXHVNFVQME8RF9ygZkcNVOsHLwKCtLP8V073puh xGpg1J6L/sTY0Dqe036sxsG0TwcCPPBm7QP99sWPXtRwafk2mk6V7M2sNwN3irakCn6zLPNSveV aIEDWk4/tn5Adorz59PaHNi3jLXuhivgXylVtBzyAgt5NAueRuXsc0mfp2Bim9dS534KKfgyv4X 3yXtH/BCJSQ8EO9aDfkp/kbHIepPKyMfPZDhXI+VSV34PVpoBELPbLJHGZ0bAW9lg+HqIzyrxzF enxf+eAGfIw9CiF5j8N64veVs2RBXEaksM3LrvkgaksGMcN4N6mlIsndLce1Zs0= X-Google-Smtp-Source: AGHT+IGedvMj7ZF9/kNTxtrfCgLzwu+cA+uF9Trw66PXzVXqXkrfSkGagniI1JbsO8J6n+jpQLBv0w== X-Received: by 2002:a05:6a00:3d02:b0:736:4e0a:7e82 with SMTP id d2e1a72fcca58-73dc1480119mr5155159b3a.10.1745019324672; Fri, 18 Apr 2025 16:35:24 -0700 (PDT) Received: from smtpclient.apple ([2601:646:8f81:6120:fcfe:cddd:f55:38ad]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-73dbfaac278sm2146972b3a.128.2025.04.18.16.35.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Apr 2025 16:35:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: [PATCH] Limit rust-ts-specific comment-start check to rust-ts (bug#77727) From: Yuan Fu In-Reply-To: Date: Fri, 18 Apr 2025 16:35:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <796789BF-C2C8-47F4-AE05-826373DF90DB@gmail.com> References: <00a518e942f09aae6d298e046f4664ed8c87341e.camel@yandex.ru> <34D65C29-C4E5-44DE-BC8A-560381945752@gmail.com> To: Konstantin Kharlamov X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 77727-done Cc: 77727-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 (-) > On Apr 18, 2025, at 2:48=E2=80=AFAM, Konstantin Kharlamov = wrote: >=20 > On Wed, 2025-04-16 at 22:58 -0700, Yuan Fu wrote: >>=20 >>=20 >>> On Apr 11, 2025, at 4:51=E2=80=AFAM, Konstantin Kharlamov >>> wrote: >>>=20 >>> On Fri, 2025-04-11 at 11:34 +0300, Konstantin Kharlamov wrote: >>>> CC: Yuan Fu as the author of the code in question. >>>>=20 >>>> What happens in the code makes sense: since the comment resides >>>> at >>>> top- >>>> level, the parent of any top-level statement (returned by >>>> (treesit- >>>> node-parent node)) is, well, beginning of a buffer. >>>>=20 >>>> So the question is, why the check works that way. >>>=20 >>> Please see the attached patch, it'd seem this is exactly the fix >>> that's >>> expected here. Basically, the problematic check is specific to Rust >>> treesitter mode, so shouldn't be executed in other languages. The >>> patch >>> factors out the entire check to a separate function and adds >>> additional >>> condition of (eq major-mode 'rust-ts-mode). >>>=20 >>> Tested in tsx-ts-mode, it fixes the problem. >>> <1.patch> >>=20 >> Thanks! Your analysis is correct. But I don=E2=80=99t want to = hard-code rust- >> ts-mode in the function, since modes with other names can very well >> use rust parser. I pushed 9d43715baa5 that operates in the similar >> vein as your patch. Instead of checking for the current major mode, I >> tighten the condition by adding an additional check that ensure the >> parent node is a comment node. So now if the parent node is the root >> node (as in your initial example), the condition should fail. Please >> see if it fixes your problem. >>=20 >> Yuan >=20 > Thank you, I confirm the problem is fixed, so bug can be closed. Great, closing the report. Yuan= From unknown Tue Jun 17 20:19:45 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 17 May 2025 11:24:11 +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