From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets Date: Fri, 24 Nov 2023 20:26:34 +0200 Message-ID: <2ba91823-bf3c-4d5d-e556-1622135ab2fd@gutov.dev> References: <83h6lbfwcu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32826"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: 67417@debbugs.gnu.org To: Eli Zaretskii , Arteen Abrishami , Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 24 19:27:24 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r6atf-0008Iq-G3 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Nov 2023 19:27:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r6atI-0008Kf-53; Fri, 24 Nov 2023 13:27:00 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r6atG-0008KC-BK for bug-gnu-emacs@gnu.org; Fri, 24 Nov 2023 13:26:58 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r6atG-0001vv-39 for bug-gnu-emacs@gnu.org; Fri, 24 Nov 2023 13:26:58 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r6atK-0006nW-9h for bug-gnu-emacs@gnu.org; Fri, 24 Nov 2023 13:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Nov 2023 18:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67417 X-GNU-PR-Package: emacs Original-Received: via spool by 67417-submit@debbugs.gnu.org id=B67417.170085041326115 (code B ref 67417); Fri, 24 Nov 2023 18:27:02 +0000 Original-Received: (at 67417) by debbugs.gnu.org; 24 Nov 2023 18:26:53 +0000 Original-Received: from localhost ([127.0.0.1]:37243 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r6atB-0006n9-D2 for submit@debbugs.gnu.org; Fri, 24 Nov 2023 13:26:53 -0500 Original-Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:37841) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r6at7-0006mv-Rt for 67417@debbugs.gnu.org; Fri, 24 Nov 2023 13:26:52 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 0EAAF3200A6F; Fri, 24 Nov 2023 13:26:38 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 24 Nov 2023 13:26:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1700850398; x=1700936798; bh=6/ntef+nXdBGPwOYB3TVVM2508VGKthegk6 VBV9I6qU=; b=cLTftL2zKDpdzBT7PxLRMceK//J3lbtpLc152O5mSl0IHtpDQfw 2qGnOIft/dfLVDRvCqJpc/rSTo0kueDsVKWp+hsq/bksL0Bj8oIXyjs6QwxZDi6f fB/29BN4XuQG8JbZSd3Sk2BPcTo9th2hlbc3cs3QrWROtCqLWy4C43Vz/ZyD9zP4 oHV4ElzFjNSzu7KV3ksjz93uyTpufSunNlxRmzFEpc4aNAO/iTGRWF6mSdIwSjiQ JpEkbsu4x8RL00Utvmgydho1xaYAZXv3r1TsrAiSunl8TmgEjcehfQNebQ1jskY5 zMyYJpPhmgvLF/BUz0HeWsiY1r8mlSXZgJQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700850398; x=1700936798; bh=6/ntef+nXdBGPwOYB3TVVM2508VGKthegk6 VBV9I6qU=; b=288w7Nv+UQzPWpbF2CBRJx+QcLxxinm+2oKGK13YbZgQhJH2ixO vnyVKhtVOlVaHV6Zo5QXB6/6aipb8r6XxbSFlaDolsp+hftZShpFOoXoXHcZNZri X2gwvpvFA7WYPFznnZr2hn4TN13ZPypLXaJAr3HQa0XozBiMUxECBAMgqSTIWrTp TE3COahIRCP6gXxGeh3cDgn9TBY7Och0EiD753KDHUu/b2RmIuHRLnDrqqxEfcnW Lu6NyZ7tiBEZISjVjwUcyMme6uoo3hJpRuTw18ZkVlVjHrVkdittXVaEuhSoj6qx d1Cd/XcY3W7zp7A9xcYhIycqp40wWsB5LaA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehhedgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeev ledvveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 24 Nov 2023 13:26:36 -0500 (EST) Content-Language: en-US In-Reply-To: <83h6lbfwcu.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:274877 Archived-At: On 24/11/2023 09:23, Eli Zaretskii wrote: >> Date: Thu, 23 Nov 2023 12:55:31 -0800 >> From: Arteen Abrishami via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> This is specifically for the usage of `c-ts-mode` and is not a problem >> in `c-mode`. Sometimes, when you type something like: >> >> else >> break >> >> it won't indent the "break" until you type a semicolon. In this below >> scenario, it does not indent the break at all, but `c-mode` does, and >> switching from `c-mode` to `c-ts-mode` with correct indentation leaves >> it fixed, but `c-ts-mode` cannot detect or fix it itself. >> >> You can put it into a `.c` buffer all by itself and see: >> >> ``` >> unsigned >> heap_pop(struct heapq * heap) >> { >> if (heap->sz == 0) >> return -1; >> >> unsigned ret_val = heap->vals[0]; >> heap->vals[0] = heap->vals[heap->len]; >> heap->len -= 1; >> unsigned i = 0; >> unsigned lc; >> >> while ((lc = HEAPQ_L_CHILD(i)) < heap->len) >> { >> unsigned rc = HEAPQ_R_CHILD(i); >> /* no right child for our guy, special case */ >> if (rc == heap->len) >> { >> if (heap->vals[lc] < heap->vals[i]) >> SWAP(heap->vals[lc], heap->vals[i]); >> break; >> } >> >> if (heap->vals[lc] < heap->vals[i]) >> { >> SWAP(heap->vals[lc], heap->vals[i]); >> i = lc; >> } >> else if (heap->vals[rc] < heap->vals[i]) >> { >> SWAP(heap->vals[rc], heap->vals[i]); >> i = rc; >> } >> else >> break; >> >> } >> } >> ``` >> >> The very last break on the else without brackets around it will not indent.c > Yuan, any comments? > > My personal take on this is that as long as typing the required > semi-colons fixes the indentation, we are okay in these cases, but if > we can do better (i.e. if the problem is not that tree-sitter returns > a tree with an error node), we should fix this even without relying on > the electric semi-colon. > > In the specific example above, it looks like tree-sitter does succeed > in parsing and shows a valid tree: > > alternative: > (else_clause else > (break_statement break ;))))) > > So I wonder why we don't indent the "break;" part here. In my testing, it indents fine when after "else" there is either: * some char(s) followed by closing curly * or (optionally) some char(s) followed by semicolon When there is _no_ code between "else" and the closing curly, it already indents fine in my testing (whether the semicolon is added or not). Without either, the text after "else" isn't parsed as "alternative:" -- it's parsed as a sibling of the "else" node. And, most unfortunately, when "else" is followed by a closing curly, it's just parsed as (ERROR else), so simply pressing RET does not indent the empty line properly even when one is working with electric-pair-mode enabled. I'd personally consider the last one a more definite bug in the grammar, but maybe there is some good reason for it. I haven't found anything relevant in the bug tracker. BTW, it seems like the latest C grammar changed how else without braces is parsed, so "break" isn't reindented even with semicolon at the end.