From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets Date: Sun, 26 Nov 2023 17:47:49 -0800 Message-ID: <8f8aa9c5-95cb-44e5-b41e-4cf58f024624@gmail.com> References: <83h6lbfwcu.fsf@gnu.org> <2ba91823-bf3c-4d5d-e556-1622135ab2fd@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3421"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 67417@debbugs.gnu.org To: Dmitry Gutov , Eli Zaretskii , Arteen Abrishami Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 27 02:49: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 1r7QkS-0000hM-0P for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 Nov 2023 02:49:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7Qk6-00007j-G1; Sun, 26 Nov 2023 20:48:58 -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 1r7Qk4-000075-Ve for bug-gnu-emacs@gnu.org; Sun, 26 Nov 2023 20:48:56 -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 1r7Qk4-0005Nt-NJ for bug-gnu-emacs@gnu.org; Sun, 26 Nov 2023 20:48:56 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r7QkA-00037A-Ar for bug-gnu-emacs@gnu.org; Sun, 26 Nov 2023 20:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Nov 2023 01:49: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.170104968611674 (code B ref 67417); Mon, 27 Nov 2023 01:49:02 +0000 Original-Received: (at 67417) by debbugs.gnu.org; 27 Nov 2023 01:48:06 +0000 Original-Received: from localhost ([127.0.0.1]:42936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r7QjF-00032B-VI for submit@debbugs.gnu.org; Sun, 26 Nov 2023 20:48:06 -0500 Original-Received: from mail-pf1-x435.google.com ([2607:f8b0:4864:20::435]:56619) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r7QjD-00030u-Dv for 67417@debbugs.gnu.org; Sun, 26 Nov 2023 20:48:05 -0500 Original-Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-6cbe6d514cdso2746279b3a.1 for <67417@debbugs.gnu.org>; Sun, 26 Nov 2023 17:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701049671; x=1701654471; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=5o3/U1L2IWDOruCNknqXfnlhLnXi4IpZ2NYvAPuhG0k=; b=NZuv/uR98fFk65Tn0YU26G5dodwDt+IhLkqwGm1xcRTe64X5839q8QYRQB877IRbxq +EwDGGJs96vstIobHoJPlCNia5EqJ1PHOuxz9lvBfHhTlkiLVa23kWWXQxFfjw3qzMG3 15Ni4slE5SnDQ/1dWRCEF3mAFof6YnvwmRlD0v7gJQJBwOclbb2y7Mb+MPfhDZwreUKS XnTVuDdF4EYg3HE4wkgnCbfZfJ3FaRbLyD6ZBE9fwj0IIxpiO4VdeNlehRzPin5uXnwv WYgrIInZN9Z0XNkd/zRhj5IumLxV1uoIlKE+0Gq/y6wY/ijRCxjP0a3mGzDj7dGadUAt bdQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701049671; x=1701654471; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5o3/U1L2IWDOruCNknqXfnlhLnXi4IpZ2NYvAPuhG0k=; b=GRu5vczVRzzuOAotTwCLVCyKScNSB7qzERQI4x+UMgLAj9JJmGwO7pv01kb3R2Jxt+ ttN/eOHTackNBElhAUk/7aGhBUyHcspAyrQWfVnh+5zJcv6ZuGbPyztUDC2fYfMNp6UD M+yoUXfl+NnwsjbhTsanz27dNREFEPVZXH/joRYlvQNIkMZazkEs2S5Ch4zMCEzpBfLc NwEc7wCz4a2ecL8OKwnU+3POTlgJ1u2jNwSiZgnaFMlq0tmcHP/7OSLfVgNOe0ccDgeR xt98OLaKIK7drZCjzftv5MNAh0OPWKqw4y9S/qGtlNCiHh6yfKqNbggWw3c5NfgdivsU 7JUw== X-Gm-Message-State: AOJu0YwXgLvOaNYjaIxXjiF070/wH7gWVjP4rz6PGL7oa0Cmj75iD3fM fKvkMfas/RPECqPXKvJXkis= X-Google-Smtp-Source: AGHT+IFn/DudS10QZ2NGGZ49qL8QxHa5eFv6X++hVSPNtRLDmQ/jOfVYDojKBhUN0x0HXFBmz26uUw== X-Received: by 2002:a05:6a00:1813:b0:6be:43f8:4e0b with SMTP id y19-20020a056a00181300b006be43f84e0bmr10001316pfa.24.1701049671256; Sun, 26 Nov 2023 17:47:51 -0800 (PST) Original-Received: from [192.168.1.7] (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id t19-20020a056a0021d300b006cb797722e6sm6149115pfj.109.2023.11.26.17.47.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Nov 2023 17:47:50 -0800 (PST) Content-Language: en-US In-Reply-To: <2ba91823-bf3c-4d5d-e556-1622135ab2fd@gutov.dev> 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:275098 Archived-At: On 11/24/23 10:26 AM, Dmitry Gutov wrote: > 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. I pushed two commits which should fix the indentation for "break" after "else", and indentation for empty lines after if/else/for/while in general. The fix for the general case doesn't use the parse tree, since the parse tree is often incomplete when you type if (...) and hit return. Instead it uses a plain regexp match to see if the previous line starts with if/else/for/while. This seems like a reasonable heuristic to use before user types more things, at which point more accurate indentation rules would be used, since the parse tree should be more complete then. Yuan