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: Tue, 28 Nov 2023 17:31:05 +0200 Message-ID: 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: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40789"; 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: Yuan Fu , Eli Zaretskii , Arteen Abrishami Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 28 16:32: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 1r804V-000APK-S5 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Nov 2023 16:32:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r8048-0005Ff-Ra; Tue, 28 Nov 2023 10:32: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 1r8043-0005EJ-CM for bug-gnu-emacs@gnu.org; Tue, 28 Nov 2023 10:31:55 -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 1r8043-0003dD-31 for bug-gnu-emacs@gnu.org; Tue, 28 Nov 2023 10:31:55 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r804A-0001Ip-0C for bug-gnu-emacs@gnu.org; Tue, 28 Nov 2023 10:32: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: Tue, 28 Nov 2023 15:32:01 +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.17011854994977 (code B ref 67417); Tue, 28 Nov 2023 15:32:01 +0000 Original-Received: (at 67417) by debbugs.gnu.org; 28 Nov 2023 15:31:39 +0000 Original-Received: from localhost ([127.0.0.1]:47440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r803m-0001IC-J2 for submit@debbugs.gnu.org; Tue, 28 Nov 2023 10:31:39 -0500 Original-Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:45291) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r803Z-0001Hn-Gl for 67417@debbugs.gnu.org; Tue, 28 Nov 2023 10:31:36 -0500 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 869E13200BDF; Tue, 28 Nov 2023 10:31:12 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 28 Nov 2023 10:31:12 -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= 1701185471; x=1701271871; bh=JcAtCU8ys5PupPuvoIDRASLvyTNJDtVU4gO TqAjj9vo=; b=vVpWxgfdKzaoV3Uy7vVjLvLG4RFbkOOYY7hvMo2c15XPIXQAGEC G2I9Jbk4LE52XjCBqro6LPNLvk7yrPPCIBvoObT1rnJQnDNHrE+XUc1kBW2wH/26 SVDMpSyb1LTEjlvqbQZnja2Jqo7PAk5bGcExlAm35wmoIyIr5X1bNiREXpvbMc54 7gu3br6+p+YrLqz2hY0g4rk/Q0ZvL7Ov7Selgm1oFWbqgX0aSPrey6qwaEGn6WD+ +TxJzW71X16U983uSHwZbU4VfcksPnTmlDHRe7Z5P0GFZKrXjBjbmQBAaYcYChp9 SxPrGa3XkkUVjv+YWlw58Ab/bkVz6FL1mVg== 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= 1701185471; x=1701271871; bh=JcAtCU8ys5PupPuvoIDRASLvyTNJDtVU4gO TqAjj9vo=; b=gK1OQt4f28+TC06/pEB40PPrZiZh0rA6/yB0AoJSauRo4R3/OLq nZeAdyIsx7MEZMTqv22VYQmddnapL52u1K4apdZL17DP3C/JueNY1N17QcJ91MX8 OS5EvVY3ichqkXhrNUsuNO2O1M5CdqoVnty9ZywkUMxlZTnONibrAQe5M8zoffIb hE9/O6ZfrT8YEZkXBreqwSBscOg7RmIltkp7QgRpR/hz4IJ9mDUXnPTqWWZwdq0U 9hFDziPwhS88qkqMbVNiNLc6TgI08VLFzy8jaXMuyp3rYnKhlyCLWmkgspSfq6HN 0Ntl9OODXLAyXvgbcbEQGd4aGaE8mlIQu3g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeifedgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 28 Nov 2023 10:31:08 -0500 (EST) Content-Language: en-US In-Reply-To: <720463fd-c6d8-4c31-8240-7017984084a4@gmail.com> 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:275170 Archived-At: 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.