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: Thu, 30 Nov 2023 23:58:14 -0800 Message-ID: <0dd74b5b-e1d2-462b-bbc3-01d0e4d71713@gmail.com> References: <83h6lbfwcu.fsf@gnu.org> <2ba91823-bf3c-4d5d-e556-1622135ab2fd@gutov.dev> <8f8aa9c5-95cb-44e5-b41e-4cf58f024624@gmail.com> <33b587b2-1ea1-f756-704f-e75a3193c147@gutov.dev> <720463fd-c6d8-4c31-8240-7017984084a4@gmail.com> 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="2418"; 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 Fri Dec 01 08:59: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 1r8yQm-0000Ua-7L for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 01 Dec 2023 08:59:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r8yQZ-0002u7-KZ; Fri, 01 Dec 2023 02:59:11 -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 1r8yQI-0002th-Mf for bug-gnu-emacs@gnu.org; Fri, 01 Dec 2023 02:58: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 1r8yQH-0006XP-TE for bug-gnu-emacs@gnu.org; Fri, 01 Dec 2023 02:58:54 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r8yQQ-00063C-2T for bug-gnu-emacs@gnu.org; Fri, 01 Dec 2023 02:59: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: Fri, 01 Dec 2023 07:59: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.170141751323218 (code B ref 67417); Fri, 01 Dec 2023 07:59:02 +0000 Original-Received: (at 67417) by debbugs.gnu.org; 1 Dec 2023 07:58:33 +0000 Original-Received: from localhost ([127.0.0.1]:55027 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r8yPw-00062Q-VA for submit@debbugs.gnu.org; Fri, 01 Dec 2023 02:58:33 -0500 Original-Received: from mail-oi1-x22c.google.com ([2607:f8b0:4864:20::22c]:57626) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r8yPu-00062B-OU for 67417@debbugs.gnu.org; Fri, 01 Dec 2023 02:58:31 -0500 Original-Received: by mail-oi1-x22c.google.com with SMTP id 5614622812f47-3b89b8d43edso141028b6e.3 for <67417@debbugs.gnu.org>; Thu, 30 Nov 2023 23:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701417496; x=1702022296; 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=5AWtoam1aaWQqiKk3xzKNnU3BUL8dCt726mJzUx3oi8=; b=fJ6b3OUdR+DOQCqNjQz8Fn57a+91dPimrwzQ76hiorXDiDL/+lqRZ9utRiFUPTePxs OqcMNWRkx4CdHhb94jZnQ+908eckUhFOMGBNKFSBee4oZRxNQ6k330C8q4xeOVfiXOGy JM/cdc4QajWBDOK7JoJ8OLNC3/8cimslt9TaZooftyKTOuZp3LURdJWbChpgMtXOzcOj rZzuYC2nJRcH1yoDZhWuG/pnzyeCRTPktJMDVMfqD+7RBzqyO1T442PkCGhzSRg9T5mj ANVOiwFbM051mu5ZCCUI3hl1kLa9fdV3I2ZiW9ZBfNySOGI+pCCwaex4pJJaHpdylH09 AjSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701417496; x=1702022296; 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=5AWtoam1aaWQqiKk3xzKNnU3BUL8dCt726mJzUx3oi8=; b=LMnY9FYBNjBc+6gd7yQIGhiyXHW6tFqgh5O1FBtQOpIL7LbnPkf01JR9tZOElmKyTM ha7HTFIwsp2rtE9D2V5DksxD0txYmZBmcivN6XGacQJQUqQ1I9vQ/0V1lmecMyGmEJOP SYj+MMHkKiYdHaoNEycFv2o7GQ0epl7Bo37YuW5hG0GlEOduOTdIbtHIakRdI0SOfmwo iyS6dTUwXwne1igpjZSHLinRZgBm7ui7Y1L67J5RnWsaaCBr6MhfUQeobBBaUOURj962 mZCxevthrUoLu3A8kYrE8Scwt/Tl1XAS03TIpNz7V3tYKUSwelE1J1plTlG4MFmzFvLS hPcg== X-Gm-Message-State: AOJu0YynX96xYLZgbrT+zhHL7wOPF2Y+vy2Uag/bLPUUNFGSkwBdaGFO 432bru5TwJZYEzF+LCxy3wc= X-Google-Smtp-Source: AGHT+IE0NxWjJ73I711NoyPN/4sAPnDfZ6DPp3aSOMOJrDNd8uV/7osnokQpAbjrQ9rMuyilGpBTXw== X-Received: by 2002:a54:4002:0:b0:3b8:37ba:7c73 with SMTP id x2-20020a544002000000b003b837ba7c73mr1757769oie.53.1701417496263; Thu, 30 Nov 2023 23:58:16 -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 g1-20020a62e301000000b006c4d86a259csm2407086pfh.28.2023.11.30.23.58.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Nov 2023 23:58:15 -0800 (PST) Content-Language: en-US In-Reply-To: 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:275309 Archived-At: On 11/28/23 7:31 AM, Dmitry Gutov wrote: > On 28/11/2023 08:55, Yuan Fu wrote: >> >> >> On 11/26/23 6:22 PM, Dmitry Gutov wrote: >>> On 27/11/2023 03:47, Yuan Fu wrote: >>>> 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. >>> >>> Sorry, two counter-examples right away: >>> >>> Type 'elsewhere();' and RET -> the next line is indented 1 level >>> extra, at least until you type some more and then have the line >>> reindented either with pressing TAB or adding semicolon. >>> >>> Type 'for (;;) {}' and RET -> same. >>> >>> The first case is easy to guard against (just check that the next >>> char is either space of opening paren), but the second one less so. >>> OTOH, the second case is likely to have a parse tree without errors, >>> so if we also check for that... the heuristic might work. >> >> Well, darn it. And you're right, the second case is a bit hard to >> check... Well I guess for the moment we can remove this heuristic. (I >> tried a bit, and checking for no errors is not so easy.) > > Maybe it's possible to salvage this heuristic a bit, at least for > "else", and as long as it's followed by "}" somewhere (e.g. when > electric-pair-mode is used). > > diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el > index 31a9d0fc886..20689dc1862 100644 > --- a/lisp/progmodes/c-ts-mode.el > +++ b/lisp/progmodes/c-ts-mode.el > @@ -373,8 +373,17 @@ c-ts-mode--indent-styles >             ;; point on the empty line to be indented; this rule >             ;; does that. >             ((and no-node > +                 ;; Could be a matcher 'prev-sibling-p'. > +                 (lambda (_ parent bol &rest _) > +                   (equal > +                    "ERROR" > +                    (treesit-node-type > +                     (treesit-node-prev-sibling > +                      (treesit-node-first-child-for-pos > +                       parent bol) > +                      t)))) >                   (c-ts-mode--prev-line-match > -                  ,(rx (or "if" "else" "while" "do" "for")))) > +                  ,(rx "else" symbol-end))) >              prev-line c-ts-mode-indent-offset) > >             ((parent-is "translation_unit") column-0 0) > > The rest of the nodes (if/while/do/for) don't result in parse errors > here, as long as the condition in parentheses is typed out correctly. > > I tried some additional clauses looking for "previous sibling", > checking whether it's for_statement, etc, which ends with "expression > statement", and that one is empty... but it a fair amount of code > which will likely miss other edge cases anyway. Or breaks when the > grammar changes. Yeah, for now we can match for the specific case where there's an else before a "}". That should reduce the chance of it matching other edge cases. I'll give it another look on this weekend. Yuan