From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets Date: Fri, 24 Nov 2023 09:23:29 +0200 Message-ID: <83h6lbfwcu.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21522"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 67417@debbugs.gnu.org To: Arteen Abrishami , Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 24 08:24:20 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 1r6QY0-0005LG-DA for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Nov 2023 08:24:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r6QXg-00006t-Lp; Fri, 24 Nov 2023 02:24: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 1r6QXe-00005E-TV for bug-gnu-emacs@gnu.org; Fri, 24 Nov 2023 02:23: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 1r6QXe-00037a-3E for bug-gnu-emacs@gnu.org; Fri, 24 Nov 2023 02:23:58 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r6QXi-0000ES-23 for bug-gnu-emacs@gnu.org; Fri, 24 Nov 2023 02:24:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Nov 2023 07:24: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.1700810627863 (code B ref 67417); Fri, 24 Nov 2023 07:24:02 +0000 Original-Received: (at 67417) by debbugs.gnu.org; 24 Nov 2023 07:23:47 +0000 Original-Received: from localhost ([127.0.0.1]:35534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r6QXT-0000Dn-1G for submit@debbugs.gnu.org; Fri, 24 Nov 2023 02:23:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55698) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r6QXR-0000Da-E8 for 67417@debbugs.gnu.org; Fri, 24 Nov 2023 02:23:45 -0500 Original-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 1r6QXH-0002jK-1f; Fri, 24 Nov 2023 02:23:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ObyD3mtFbn7mAIuUkp0qbL2ccbN7QimcTiaUW71/nsA=; b=Cg/Pn1Q5A9AZ x3ksbFmBDjUJQh0GUnnv7We7zbZPQ49343JWF6rfYXbUPE+Vw0mve1Ay0DSPVxvSrZxDe/sh7JHmz xWxJGDisV9JaZOM5QQjxUg0K3EvqBHsAAXVAUMUTFU82jq53ihhC8fe9TbSJVGQPcTkH22CAWMoAp RukEd+fVOGHE0nwK3vOtrtXk+ib1HuaHCUcJo2LNKvDvNzqD2mj42u5r2EOaF00hnY/NtNliShziV r5SAv4+LqiLDHxsgs4m3OXZ6ya18laciFZxfYRbh5hiAtz7Qh5hOzD6r4MFUaQLTylcGAEsJGMX5U btyKz5LQnWKNpioKIYQh5w==; In-Reply-To: (bug-gnu-emacs@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:274841 Archived-At: > 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. Comparison with c-mode is not relevant here, btw, since c-mode uses a very different strategy for computing indentation.