From unknown Fri Jun 20 07:09:40 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#67417 <67417@debbugs.gnu.org> To: bug#67417 <67417@debbugs.gnu.org> Subject: Status: 29.1.50; c-ts-mode syntax issues with no brackets Reply-To: bug#67417 <67417@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:09:40 +0000 retitle 67417 29.1.50; c-ts-mode syntax issues with no brackets reassign 67417 emacs submitter 67417 Arteen Abrishami severity 67417 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 23 16:59:50 2023 Received: (at submit) by debbugs.gnu.org; 23 Nov 2023 21:59:50 +0000 Received: from localhost ([127.0.0.1]:35282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r6Hjg-0001py-Nn for submit@debbugs.gnu.org; Thu, 23 Nov 2023 16:59:49 -0500 Received: from lists.gnu.org ([2001:470:142::17]:45644) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r6Gjt-0008NF-4c for submit@debbugs.gnu.org; Thu, 23 Nov 2023 15:55:57 -0500 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 1r6Gjj-0003lW-DC for bug-gnu-emacs@gnu.org; Thu, 23 Nov 2023 15:55:47 -0500 Received: from linux.ucla.edu ([131.179.104.10]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r6Gjh-00071F-9r for bug-gnu-emacs@gnu.org; Thu, 23 Nov 2023 15:55:47 -0500 Received: from smtpclient.apple (cpe-70-95-151-149.san.res.rr.com [70.95.151.149]) by linux.ucla.edu (Postfix) with ESMTPSA id 09F4BEC108E for ; Thu, 23 Nov 2023 12:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux.ucla.edu; s=mail; t=1700772942; bh=y5qRP2GrnqFYop10wvABWAO2WtnmJ4+l2ZcrKoWOK5c=; h=From:Subject:Date:To:From; b=SlRRpoB2Y5zv+3doMmX9eKbLsRRvOfoRUd8fWQpi3oim+rv7Q+FHRdxeJtEgN99QV +95Cd2IzASXfINOP3fZ7QuFsaye6irPZ5WeGnodY+feFy8BOXoz2ymvun73TwuSwU9 nyyuRhZoPcFuqRvt0dd5WVz6NT+Ib1wKhNKITjbg5EbBYh/g3Zk8SCIlG8Ntga2vD4 HHQP9z/M9g868jQ6k7z6TvNL5aL//MQmBMB+ZjVKh5ASpisLD/cjdYjEWoB3dDvfHJ NiyRU41CfQlideXlNtSZM1zuI5gAYu7pmTERWSkc78YSnQGKv08pFaWbXXZ0L9LHk1 HxuotBQJjpSNA== From: Arteen Abrishami Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: 29.1.50; c-ts-mode syntax issues with no brackets Message-Id: Date: Thu, 23 Nov 2023 12:55:31 -0800 To: bug-gnu-emacs@gnu.org X-Mailer: Apple Mail (2.3774.200.91.1.1) Received-SPF: pass client-ip=131.179.104.10; envelope-from=arteen@linux.ucla.edu; helo=linux.ucla.edu X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 23 Nov 2023 16:59:44 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) 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 =3D=3D 0) return -1; unsigned ret_val =3D heap->vals[0]; heap->vals[0] =3D heap->vals[heap->len]; heap->len -=3D 1; unsigned i =3D 0; unsigned lc; while ((lc =3D HEAPQ_L_CHILD(i)) < heap->len) { unsigned rc =3D HEAPQ_R_CHILD(i); /* no right child for our guy, special case */ =20 if (rc =3D=3D 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 =3D lc; } else if (heap->vals[rc] < heap->vals[i]) { SWAP(heap->vals[rc], heap->vals[i]); i =3D rc; } else break; =20 } } ``` The very last break on the else without brackets around it will not = indent.c In GNU Emacs 29.1.50 (build 2, x86_64-apple-darwin23.0.0, NS appkit-2487.00 Version 14.0 (Build 23A344)) of 2023-09-30 built on Arteens-MacBook-Pro.local Repository revision: 63ec6d998d42c970a825dca17743ece9c651d929 Repository branch: emacs-29 Windowing system distributor 'Apple', version 10.3.2487 System Description: macOS 14.1.1 Configured using: 'configure --with-native-compilation=3Daot --without-pop --with-tree-sitter --with-json 'CFLAGS=3D-O2 -pipe' = CPPFLAGS=3D-I/usr/local/opt/openjdk/bin:/usr/local/opt/openjdk/bin:/usr/lo= cal/opt/make/libexec/gnubin:/usr/local/opt/python@3.11/libexec/bin:/usr/lo= cal/sbin:/Library/Frameworks/Python.framework/Versions/3.11/bin:/usr/local= /bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/= com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/= com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.ap= ple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Librar= y/Apple/usr/bin:/Library/TeX/texbin' Configured features: ACL GIF GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY KQUEUE NS PDUMPER PNG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER XIM ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: C/* Minor modes in effect: override-global-mode: t windmove-mode: t winner-mode: t delete-selection-mode: t global-auto-revert-mode: t tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t hs-minor-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message yank-media puny rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util text-property-search mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils c++-ts-mode c-ts-mode c-ts-common treesit misearch multi-isearch time-date comp comp-cstr warnings icons vc-git diff-mode vc-dispatcher cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs hideshow dired-subtree dired-hacks-utils dired dired-loaddefs dash edmacro kmacro use-package-bind-key bind-key easy-mmode rx doom-themes-ext-org doom-themes-ext-visual-bell face-remap doom-vibrant-theme doom-themes doom-themes-base exec-path-from-shell cl-extra help-mode use-package-ensure use-package-core windmove winner ring delsel autorevert filenotify dired-sidebar-autoloads dired-subtree-autoloads dired-hacks-utils-autoloads info dash-autoloads doom-themes-autoloads exec-path-from-shell-autoloads expand-region-autoloads package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads kqueue cocoa ns lcms2 multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 240395 9962) (symbols 48 13899 0) (strings 32 41716 3048) (string-bytes 1 1380541) (vectors 16 26557) (vector-slots 8 519687 16325) (floats 8 260 374) (intervals 56 5432 0) (buffers 984 16)) From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 24 02:23:47 2023 Received: (at 67417) by debbugs.gnu.org; 24 Nov 2023 07:23:47 +0000 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 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 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==; Date: Fri, 24 Nov 2023 09:23:29 +0200 Message-Id: <83h6lbfwcu.fsf@gnu.org> From: Eli Zaretskii To: Arteen Abrishami , Yuan Fu In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67417 Cc: 67417@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 24 13:26:53 2023 Received: (at 67417) by debbugs.gnu.org; 24 Nov 2023 18:26:53 +0000 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 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 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) 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 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 24 Nov 2023 13:26:36 -0500 (EST) Message-ID: <2ba91823-bf3c-4d5d-e556-1622135ab2fd@gutov.dev> Date: Fri, 24 Nov 2023 20:26:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets Content-Language: en-US To: Eli Zaretskii , Arteen Abrishami , Yuan Fu References: <83h6lbfwcu.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83h6lbfwcu.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 67417 Cc: 67417@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.9 (---) 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 26 20:48:06 2023 Received: (at 67417) by debbugs.gnu.org; 27 Nov 2023 01:48:06 +0000 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 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 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) 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) Message-ID: <8f8aa9c5-95cb-44e5-b41e-4cf58f024624@gmail.com> Date: Sun, 26 Nov 2023 17:47:49 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets Content-Language: en-US To: Dmitry Gutov , Eli Zaretskii , Arteen Abrishami References: <83h6lbfwcu.fsf@gnu.org> <2ba91823-bf3c-4d5d-e556-1622135ab2fd@gutov.dev> From: Yuan Fu In-Reply-To: <2ba91823-bf3c-4d5d-e556-1622135ab2fd@gutov.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67417 Cc: 67417@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 26 21:23:12 2023 Received: (at 67417) by debbugs.gnu.org; 27 Nov 2023 02:23:12 +0000 Received: from localhost ([127.0.0.1]:43004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r7RHD-00046h-T9 for submit@debbugs.gnu.org; Sun, 26 Nov 2023 21:23:12 -0500 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:36433) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r7RH9-00046C-V6 for 67417@debbugs.gnu.org; Sun, 26 Nov 2023 21:23:11 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id AAAAA32001E9; Sun, 26 Nov 2023 21:22:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 26 Nov 2023 21:22:56 -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= 1701051775; x=1701138175; bh=iGEA9YPeWlzyBsqkw2geFi6rFSBSgrFj6Gb 2/RfT3CA=; b=TPiZsJMcBs4D0oHpivZsQuFWx18GxrwnLvsI/V0DV7PRDItiQgD nMK3d3CyqxUyItygF4LT2Mmxti8vgHWm10lfWJuQr9c70x7ksE5y9cM/YTUiM7L/ 9Larz11HU3bs23JNEBsf2X0Wi/hRVL8eKohcenRuoqoirRKlJG6f7p+V5xFRpEcc FP29D16WPvyjMAytqKeNgA7jZ45jI/KDDbZXLhFQRwkKpb7nD5i76dASgNs5Az6Q z2r4FpYFl/qSsaTZYB78SU4odqJtnhjmJNxT32JPgPxR1kNa8ObMgeuvlwiAxsT2 pExTbRf0UYaW524lsaDIgVXWYSrZ3GCeumQ== 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= 1701051775; x=1701138175; bh=iGEA9YPeWlzyBsqkw2geFi6rFSBSgrFj6Gb 2/RfT3CA=; b=XBKD+BqQNoRT2RqwuaTZ1Y4rLngXAFZrKjv6r72ZHY9b3ywxRX+ u7aWKcrYgGPhYcr0gk3wSX9ZonXbTk8Edn28ePE+HTT/4zbDMljilN5Uy0OJRg5+ oX5G6NZXZX3v2Ix3Z/nh9ikw8iLpUgOJYbAbtxI2dg0NLzvwqKoQJRkx0PS2ohLA 2U3Lsp5COFFIjaK2zHsTQMTV+bPWdla2pcu/RwgQ5+VVpD1XaPSvahojPHfSqXwY WNibd1WH85TknJ+uzyYMCNGDptfuelwZ5LHkRQOGIjsnYtAbeuIVr9RtTL0HbfeZ yQHhhQWsJqorGn1s+7ymUp0iMC/NUg8riqA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeitddggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 26 Nov 2023 21:22:53 -0500 (EST) Message-ID: <33b587b2-1ea1-f756-704f-e75a3193c147@gutov.dev> Date: Mon, 27 Nov 2023 04:22:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets Content-Language: en-US To: Yuan Fu , Eli Zaretskii , Arteen Abrishami References: <83h6lbfwcu.fsf@gnu.org> <2ba91823-bf3c-4d5d-e556-1622135ab2fd@gutov.dev> <8f8aa9c5-95cb-44e5-b41e-4cf58f024624@gmail.com> From: Dmitry Gutov In-Reply-To: <8f8aa9c5-95cb-44e5-b41e-4cf58f024624@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 67417 Cc: 67417@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.9 (---) 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 28 01:55:49 2023 Received: (at 67417) by debbugs.gnu.org; 28 Nov 2023 06:55:49 +0000 Received: from localhost ([127.0.0.1]:45365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r7s0a-0004GN-LZ for submit@debbugs.gnu.org; Tue, 28 Nov 2023 01:55:48 -0500 Received: from mail-pf1-x434.google.com ([2607:f8b0:4864:20::434]:44474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r7s0Y-0004G9-BK for 67417@debbugs.gnu.org; Tue, 28 Nov 2023 01:55:46 -0500 Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-6cbe5b6ec62so4066257b3a.1 for <67417@debbugs.gnu.org>; Mon, 27 Nov 2023 22:55:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701154533; x=1701759333; 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=28UsWwDVyphrWnAaMwvmr4cfVXmfYLiWEK16E0zUKgE=; b=CgjixL9NOlB6PPO3uaNj5oiPc/cSsqLkn1XXKMhIO6ZSemC8pBp/JM1FlflBj8e81h nU+nnlCXdLSOWy/92GiOWJdjnDpnEkezTd78iodtLGXEsE2RxGWQ5Vh2A/DJALmTzpmx X4HD1Mj6KNAsi/yXC3sBxO49XKvp7YtpnI3GguLolb/QqBAgt/CTiQioC58kzNZUY3Vp ORDvdm0ywPQakfNvL4uJ4eTGNz6sC7CMTxkmIT1SoHdRNZfWZqnuQeUaixEVS6f7j57k VFrs/DlbRqOvDm56U9GonhmCxKg2CWY1drAqkh1/i848dwr58xRIqLay2EUojwZ8j9Uu CH4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701154533; x=1701759333; 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=28UsWwDVyphrWnAaMwvmr4cfVXmfYLiWEK16E0zUKgE=; b=jVRI2YTo6JEKg9OdlpGMHRzJMShO78doK76ZxkzAXmQSSVDBG7YPJOA05TTSSeGvJS l5M1O4vajkTH81hkZ6c8jrbQdZ+pFxQcsGrjwDqHpphoTCYpDfxwnw/kTBH17ql76pgH 6Ea58VBestKmSJdyfSe9E+Gcpq9jTL+uuHOEtb+mjUwnMIGzj5PbLJczd6Qu0CGu8IHl q7R137G4s+nnGZGK4m0SMmhXCXA/yEirXthgFwnHAApmlUU/Mz/fB7wsfrZVlVjKCd0L +c4PaJdR19IKpyLPIUuK9wosjSlfsLBMl/fsuwCJsY5OdWpSydn4zdx86vOr570NvR0m kSMg== X-Gm-Message-State: AOJu0YznIks81e0mjiyzLHscBMu+iwnwcsLqtq7WAEgeEE808ibos1BU WwfVZh59e067bpBf76yHtXE= X-Google-Smtp-Source: AGHT+IGkZ1tyUTMvv2vRJl45fgbxg21tJ6yJiDD7M5wqek34VgQhTcq8wUe4Ye6bJVbCEYJ4kyZIoQ== X-Received: by 2002:a05:6a20:8f19:b0:188:39e:9054 with SMTP id b25-20020a056a208f1900b00188039e9054mr17094651pzk.6.1701154533227; Mon, 27 Nov 2023 22:55:33 -0800 (PST) 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 rs11-20020a17090b2b8b00b002802d9d4e96sm8811538pjb.54.2023.11.27.22.55.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Nov 2023 22:55:32 -0800 (PST) Message-ID: <720463fd-c6d8-4c31-8240-7017984084a4@gmail.com> Date: Mon, 27 Nov 2023 22:55:31 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets Content-Language: en-US To: Dmitry Gutov , Eli Zaretskii , Arteen Abrishami 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> From: Yuan Fu In-Reply-To: <33b587b2-1ea1-f756-704f-e75a3193c147@gutov.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67417 Cc: 67417@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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.) Yuan From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 28 09:28:08 2023 Received: (at 67417) by debbugs.gnu.org; 28 Nov 2023 14:28:09 +0000 Received: from localhost ([127.0.0.1]:45875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r7z4K-0002Ot-7h for submit@debbugs.gnu.org; Tue, 28 Nov 2023 09:28:08 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44928) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r7z4F-0002OV-Ir for 67417@debbugs.gnu.org; Tue, 28 Nov 2023 09:28:06 -0500 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 1r7z42-0002Io-KL; Tue, 28 Nov 2023 09:27:50 -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=i8+85OAtXH73Zxj6zf9/KvFHTNsxgD7zP79ZGEDzzsw=; b=RAObwKNWjmw+ 1HgJOngoy6G4Qe+DYIwizzIDQ1vOJEIyk4EEYQC+4/bXm7F6ajmdH9/m8eCBE2Zc+K3gl5z+HeYq9 B2tAajS3xuJGbv8U9IhsZlaJc3joYSNDoaVXmwrII1WgQ+gJ+81ziarMTpLFxYMMVWB9iicVS0SDO IV6lp7vAZDNywvMkZzSffPFBhzDa0LcnK+uVQtX6m8n6Dti7CZ6qhPUnjmTpFInlJteBhwsRhBfy+ BSkdYM7ygjq5jUbkFy5GeHWY9o/fhsRg5GYEVEVC7IauEmYYRycY5V58x3j7jHelQCuBH1Kh3uicv Aeb6gV5kC/JD+5p7vJi9eg==; Date: Tue, 28 Nov 2023 16:27:37 +0200 Message-Id: <83cyvu7y1y.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: <720463fd-c6d8-4c31-8240-7017984084a4@gmail.com> (message from Yuan Fu on Mon, 27 Nov 2023 22:55:31 -0800) Subject: Re: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67417 Cc: 67417@debbugs.gnu.org, dmitry@gutov.dev, arteen@linux.ucla.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 27 Nov 2023 22:55:31 -0800 > Cc: 67417@debbugs.gnu.org > From: Yuan Fu > > > > 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.) Does this mean you need to revert something on the emacs-29 branch? From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 28 10:31:39 2023 Received: (at 67417) by debbugs.gnu.org; 28 Nov 2023 15:31:39 +0000 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 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 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) 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 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 28 Nov 2023 10:31:08 -0500 (EST) Message-ID: Date: Tue, 28 Nov 2023 17:31:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets Content-Language: en-US To: Yuan Fu , Eli Zaretskii , Arteen Abrishami 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> From: Dmitry Gutov In-Reply-To: <720463fd-c6d8-4c31-8240-7017984084a4@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) X-Debbugs-Envelope-To: 67417 Cc: 67417@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.9 (---) 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 01 02:58:33 2023 Received: (at 67417) by debbugs.gnu.org; 1 Dec 2023 07:58:33 +0000 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 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 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) 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) Message-ID: <0dd74b5b-e1d2-462b-bbc3-01d0e4d71713@gmail.com> Date: Thu, 30 Nov 2023 23:58:14 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets Content-Language: en-US To: Dmitry Gutov , Eli Zaretskii , Arteen Abrishami 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> From: Yuan Fu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67417 Cc: 67417@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 09 03:27:49 2023 Received: (at 67417) by debbugs.gnu.org; 9 Dec 2023 08:27:49 +0000 Received: from localhost ([127.0.0.1]:46771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBsgb-0002Pe-VK for submit@debbugs.gnu.org; Sat, 09 Dec 2023 03:27:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46498) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rBsgb-0002PS-4g for 67417@debbugs.gnu.org; Sat, 09 Dec 2023 03:27:45 -0500 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 1rBsgH-0002Ja-J7; Sat, 09 Dec 2023 03:27:25 -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=tXdVyHc1vDBiPn/sbaKghAgzXM10BmlyiFAm150qVQM=; b=Ex/IDAsfUyNU HY4yofKQS0CYxwKK1EcP6mnYpQJeBTGEZBFu+I6h3gixEmQ4iTLlT5EqpkjDVw+1pw7Y0vRT9Yyba eC+RLx3077EpQKVyK26w+ltGkxmMWkMVGDVjKet/rDk0Dkj1MCpKo9Whxpgi2qay3TefcgfV4SDUq At5cKCDl9sUUkRp6zijHdX7fhFWkcE/wUvSfUr1Cq6WA42cMnvmmmYfitF7RPsqIumPTN7n/jvBab ajt49wmYSBNhVJjR3F/guCX8lalSQee4bEwh2LScg49nw42uvFZkY39G7M5a33GDdvCI1zyi9DYQm luhZFmkKTGpYAYmRkTcq4w==; Date: Sat, 09 Dec 2023 10:27:09 +0200 Message-Id: <83plzfye5e.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: <0dd74b5b-e1d2-462b-bbc3-01d0e4d71713@gmail.com> (message from Yuan Fu on Thu, 30 Nov 2023 23:58:14 -0800) Subject: Re: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets 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> <0dd74b5b-e1d2-462b-bbc3-01d0e4d71713@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67417 Cc: 67417@debbugs.gnu.org, dmitry@gutov.dev, arteen@linux.ucla.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 30 Nov 2023 23:58:14 -0800 > Cc: 67417@debbugs.gnu.org > From: Yuan Fu > > > 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. Any progress here? From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 10 04:29:27 2023 Received: (at 67417) by debbugs.gnu.org; 10 Dec 2023 09:29:27 +0000 Received: from localhost ([127.0.0.1]:49488 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rCG7q-0004v8-WC for submit@debbugs.gnu.org; Sun, 10 Dec 2023 04:29:27 -0500 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]:42083) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rCG7o-0004us-Nn for 67417@debbugs.gnu.org; Sun, 10 Dec 2023 04:29:25 -0500 Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1d04c097e34so26561935ad.0 for <67417@debbugs.gnu.org>; Sun, 10 Dec 2023 01:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702200545; x=1702805345; 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=YMP8wFCnhsqRMpc/z5Vf/Bee/ymwfIjD0ecqR7Olzjs=; b=Q9ZY2kjAO9KLFcuVnXUsGYXPX7ma1XnIu4hIebE0f+dXcFZCcyj2AAeT7JONrIdF6d PZD7I7JJZ1IUzN/SNeIZnJRKwIBRb1RBMVQrUZ4b6/oQQ1FMQFxX3nTUYPTyX3YIj0A6 kjg6fY++4vnt+L5wz1dFEBJkbHBcXYwtyJdVZEglqK4kolb4PfM9ShvT77TF9/Y2XN30 uFW2/DPd8UBsDYEGA8e71lzNJ9W4rWaggcLiJR87BPMdSMPJJIDqI9CBlyURry4n288U G6TXVTv89eco2UEsraGK7ZitVnoS3mvMaGujBN+wQ5+T3yfMGeG2nG+uZvNaTj9iwdZA 9pNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702200545; x=1702805345; 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=YMP8wFCnhsqRMpc/z5Vf/Bee/ymwfIjD0ecqR7Olzjs=; b=JlqqaV2NqRE3KDNUsiMkY+KhbuUlB8nhDZ7pv4Pz+5I5fuewM67dc6p6w1j3/SU1lw KjWrB5AGcWBF7tWeciQvOTPflHLfxsbFH9H15k1DiAKXymTE47u7E/WH1AKOxCnI0NWd fQfol0nlevmMNMGBQfbOvpBP6JvVxZwRsq3M6pAiO2i+u0T82fGzHbeabwGLeFqjK4/I PxtoYnrlk09f6PsEbU3qlDmdBj417h4rF3I+1sSeExHLITjmL8H+iKIXzmOqYTEaXPBy rQ9xwJgHSAqqdAWhzi5X1gpLIvWMk8KNgl+TurLyfXCkJ7h5aBgzgzRnuH2ilFJrTQXh vqng== X-Gm-Message-State: AOJu0Ywt629sRkXZuAiT4Owr/o5cUJO7202OzPslDbES+dT0cgIfpi2c pZWV+W9jimVQ5ryY+kEwNxE= X-Google-Smtp-Source: AGHT+IHqDCt/GTrONVeKLwBPdqhIMv3JMt8XnDfWNRPq1lnKzbNr94dOdr7QTeGN1WLtwkpzaC6h9w== X-Received: by 2002:a17:903:41c1:b0:1d0:6ffd:611c with SMTP id u1-20020a17090341c100b001d06ffd611cmr3095324ple.62.1702200544647; Sun, 10 Dec 2023 01:29:04 -0800 (PST) Received: from [192.168.1.7] (172-117-161-177.res.spectrum.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id l4-20020a170903244400b001d060c61da5sm4500524pls.134.2023.12.10.01.29.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 Dec 2023 01:29:04 -0800 (PST) Message-ID: Date: Sun, 10 Dec 2023 01:29:03 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets Content-Language: en-US To: Eli Zaretskii 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> <0dd74b5b-e1d2-462b-bbc3-01d0e4d71713@gmail.com> <83plzfye5e.fsf@gnu.org> From: Yuan Fu In-Reply-To: <83plzfye5e.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67417 Cc: 67417@debbugs.gnu.org, dmitry@gutov.dev, arteen@linux.ucla.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 12/9/23 12:27 AM, Eli Zaretskii wrote: >> Date: Thu, 30 Nov 2023 23:58:14 -0800 >> Cc: 67417@debbugs.gnu.org >> From: Yuan Fu >> >>> 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. > Any progress here? I pushed a commit that changes the too-board heuristic to only match "else before closing bracket". Hopefully this won't cause any false matches. I think we can close this. Dmitry, WDYT? Yuan From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 10 19:30:17 2023 Received: (at 67417-done) by debbugs.gnu.org; 11 Dec 2023 00:30:17 +0000 Received: from localhost ([127.0.0.1]:52121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rCUBc-0002iM-SI for submit@debbugs.gnu.org; Sun, 10 Dec 2023 19:30:17 -0500 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:48927) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rCUBa-0002i4-M2 for 67417-done@debbugs.gnu.org; Sun, 10 Dec 2023 19:30:15 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 0A0263200A89; Sun, 10 Dec 2023 19:29:52 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 10 Dec 2023 19:29:53 -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= 1702254592; x=1702340992; bh=Rv85m/MuBhXUql/Lb1WF3P5sxcp+NlvfwQ3 z++BVSAg=; b=NOouN1FNoxfBVhQP7/jpSL/LALTTc0UwHg5q4639yqKOcEBODE/ 6E12Ti6fu3lssY8O/xyeSXHYtUQaSHjjwzZZ4OYImwsGZ29YXopev7rito4mgvBQ jyneTzXFIPom9mGYvgHLNU7t/2Ms2mzvboAIeeuD/t2duTg9Y3Y14JXzZS0PJi35 HZiWRsz4xt6+5u/bfNbTZ1hnxLELg25ReyPF6IvXAclZ5DxfmMdz8Qi//4uz/XOF 40ekJ6rYC9UdboeLnGsRkw5hloEw9icx9fForW2wtcwbZLfrNAlkcMWV5npQA8zt zNx/RN6GMyr15VeaK7n0XgWKoS4zqa1gvPA== 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= 1702254592; x=1702340992; bh=Rv85m/MuBhXUql/Lb1WF3P5sxcp+NlvfwQ3 z++BVSAg=; b=Uf4cC5AcEw+d3Gs2c6gAxCuR+V3wmaWoj0RkOaZSrWGnXiNomZc Fm1XaWF0IJM04iu/gpdD8C5fvjXLRxfSRqJvb1ZAzHDHEWnTULNiJVU3JtMpyGit ExAyEUBEtNpGkjPyFQcTQFz8Ugn+3Ie+id8PmsFGag5QJJjUWvrciKlepzXHzx6K gXZotzRuiHslU6udbugENNqxVKmaAuCi9Cg+bCVDLihjnJMxedhSuqIyWCeubF+Z 2Fz2gP/tDlRgfJABRhZg1LcF+92G73XKZLcrRLN4j5oDL7FNlxIQNL0VtJFFZ6nO 23DR8sxhD9TWZALUeoq8MhCLlx5yj3vkwlg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeluddgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 10 Dec 2023 19:29:50 -0500 (EST) Message-ID: Date: Mon, 11 Dec 2023 02:29:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#67417: 29.1.50; c-ts-mode syntax issues with no brackets Content-Language: en-US To: Yuan Fu , Eli Zaretskii 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> <0dd74b5b-e1d2-462b-bbc3-01d0e4d71713@gmail.com> <83plzfye5e.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 67417-done Cc: 67417-done@debbugs.gnu.org, arteen@linux.ucla.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.9 (---) Version: 29.2 On 10/12/2023 11:29, Yuan Fu wrote: > > > On 12/9/23 12:27 AM, Eli Zaretskii wrote: >>> Date: Thu, 30 Nov 2023 23:58:14 -0800 >>> Cc: 67417@debbugs.gnu.org >>> From: Yuan Fu >>> >>>> 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. >> Any progress here? > I pushed a commit that changes the too-board heuristic to only match > "else before closing bracket". Hopefully this won't cause any false > matches. > > I think we can close this. Dmitry, WDYT? LGTM! (And closing.) Arteen, let us know if you see any problems with the fixes that are now in the emacs-29 branch. From unknown Fri Jun 20 07:09:40 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 08 Jan 2024 12:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator