From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Feb 2023 20:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 61558@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.167658049727318 (code B ref -1); Thu, 16 Feb 2023 20:49:01 +0000 Received: (at submit) by debbugs.gnu.org; 16 Feb 2023 20:48:17 +0000 Received: from localhost ([127.0.0.1]:37769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSlAu-00076V-UU for submit@debbugs.gnu.org; Thu, 16 Feb 2023 15:48:17 -0500 Received: from lists.gnu.org ([209.51.188.17]:54154) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSlAs-00076C-GX for submit@debbugs.gnu.org; Thu, 16 Feb 2023 15:48:14 -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 1pSlAq-0005aJ-U9 for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2023 15:48:12 -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 1pSlAq-0004ed-HJ for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2023 15:48:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Subject:To:From:Date:mime-version:in-reply-to: references; bh=MdLiJomCevJtjMG5W7HQvKiul6cGcejjG46yxS77UnI=; b=Er7owd0BkTBJnT CRsyJuu4SbCdOgUa/F0cCdB1U6hj4zRHnabVjGzYFQ3W4J1Futq3DNUOdAigIggVEBbP9gvQN4lzf RVoz2kS/8tnP+jP4nAGj1bQvxyTrWApx/BoDJpUDmPR4Dz5d3PJjzo2t+VWGJXDovzyp7Syj0d1Cj ETzPS3luxaMMducReB1mUKV2zDxdb41FRdfXXBs1tQf2NwrYXAkBzofxluqfBUqGomK+g3hWcIOvX fzfn5Z+xkiBZUnXugxTr034xqCDCpIcPTR5cQYr8zFW1n5PNzUV+c1DB6aAvTvO06rTfTjcX7DvED 9YlErDGh9nR1jXvlo79Q==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pSlAq-0003n1-01 for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2023 15:48:12 -0500 Date: Thu, 16 Feb 2023 22:48:09 +0200 Message-Id: <835yc12v7a.fsf@gnu.org> From: Eli Zaretskii X-Spam-Score: -2.3 (--) 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 (---) To reproduce: emacs -Q C-x C-f src/dispnew.c RET C-u 265 M-g g C-e RET The code around there looks like this: static struct glyph_matrix * new_glyph_matrix (struct glyph_pool *pool) { struct glyph_matrix *result = xzalloc (sizeof *result); #if defined GLYPH_DEBUG && defined ENABLE_CHECKING /* Increment number of allocated matrices. This count is used to detect memory leaks. */ ++glyph_matrix_count; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< #endif Line 265 is the one indicated with "<<<<<<". Pressing RET goes to column 0, not column 2 as expected. It looks like indentation doesn't work in code fragments that are guarded by #ifdef..#endif preprocessor conditions. I tried several such places, for example, lines 295, 796, 1338, 1360, 1745, 2401, 2615, and many more. Strangely, in other places indentation does work: lines 1069, 3119. In GNU Emacs 29.0.60 (build 326, i686-pc-mingw32) of 2023-02-16 built on HOME-C4E4A596F7 Repository revision: f1f571e72ae10285762d3a941e56f7c4048272af Repository branch: emacs-29 Windowing system distributor 'Microsoft Corp.', version 5.1.2600 System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600) Configured using: 'configure -C --prefix=/d/usr --with-wide-int --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: C Minor modes in effect: tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x 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-common treesit cl-seq vc-git diff-mode easy-mmode vc vc-dispatcher bug-reference byte-opt gv bytecomp byte-compile cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars 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 w32notify w32 lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 80960 11004) (symbols 48 9604 0) (strings 16 28428 2568) (string-bytes 1 916238) (vectors 16 15765) (vector-slots 8 208391 13142) (floats 8 28 52) (intervals 40 1627 87) (buffers 888 11)) From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Feb 2023 19:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 61558@debbugs.gnu.org Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.167666181921883 (code B ref 61558); Fri, 17 Feb 2023 19:24:01 +0000 Received: (at 61558) by debbugs.gnu.org; 17 Feb 2023 19:23:39 +0000 Received: from localhost ([127.0.0.1]:41587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pT6KZ-0005gs-Gd for submit@debbugs.gnu.org; Fri, 17 Feb 2023 14:23:39 -0500 Received: from out0.migadu.com ([94.23.1.103]:18348) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pT6KW-0005gj-HB for 61558@debbugs.gnu.org; Fri, 17 Feb 2023 14:23:37 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1676661815; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LGaX0po45kuMNBJdMkNAmhL2Mo5knIcvVonQg00MFp8=; b=OPbR+GpW1Meq6QxBS2UPoB8rZyx+3JAhR9ZUGbwsR+ShPkj2e3KqVbi3h7kXtElSYs8acH xljbLbPRk0hkwny5AkTWKWGdZ6oTfaCVDgNW4qArTOdXPQ8SURo1gc/KPTFD4a1Wzd5qbo nWYp8gPJl9Vl2XpGSgTWh63jsjafZcJYpmVzRc6i5r9+R9AtC2/ZSFfFpx1o3y6wqVYquZ IgxCV+IJN3ubVB+tvwIxqHbHU2BlyUlqykomR9x7Z1w6Y6yyVF+1WHWjocwch1SJtSBXrw S6dReddEFWbFwXHIQK6b55ZBRToIsLkJqHM0t9dr/mCazxYW3H6tBuWAVMnnCA== From: Theodor Thornhill In-Reply-To: <835yc12v7a.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 16 Feb 2023 22:48:09 +0200") References: <835yc12v7a.fsf@gnu.org> Date: Fri, 17 Feb 2023 20:23:33 +0100 Message-ID: <87cz68p03u.fsf@thornhill.no> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Spam-Score: -0.7 (/) 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.7 (-) Eli Zaretskii writes: > To reproduce: > > emacs -Q > C-x C-f src/dispnew.c RET > C-u 265 M-g g > C-e > RET > > The code around there looks like this: > > static struct glyph_matrix * > new_glyph_matrix (struct glyph_pool *pool) > { > struct glyph_matrix *result = xzalloc (sizeof *result); > > #if defined GLYPH_DEBUG && defined ENABLE_CHECKING > /* Increment number of allocated matrices. This count is used > to detect memory leaks. */ > ++glyph_matrix_count; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > #endif > > Line 265 is the one indicated with "<<<<<<". Pressing RET goes to > column 0, not column 2 as expected. It looks like indentation doesn't > work in code fragments that are guarded by #ifdef..#endif preprocessor > conditions. I tried several such places, for example, lines 295, 796, > 1338, 1360, 1745, 2401, 2615, and many more. > Yep. We need rules for these in particular. They aren't really straightforward because the expected indent style varies, afaict. For example: #ifdef WINDOWSNT #include "w32.h" #endif compared to #if defined GLYPH_DEBUG && defined ENABLE_CHECKING /* Increment number of allocated matrices. This count is used to detect memory leaks. */ ++glyph_matrix_count; #endif Is it a correct assuption to think that whatever is inside one of these if-blocks should indent according to their grand-parents rule? In this case: static struct glyph_matrix * new_glyph_matrix (struct glyph_pool *pool) { struct glyph_matrix *result = xzalloc (sizeof *result); #if defined GLYPH_DEBUG && defined ENABLE_CHECKING /* Increment number of allocated matrices. This count is used to detect memory leaks. */ ++glyph_matrix_count; #endif /* Set pool and return. */ result->pool = pool; return result; } ++glyph_matrix_count; is indented one step from the compound_statement node, right? So we need a way to "ignore" the parents indentation. > Strangely, in other places indentation does work: lines 1069, 3119. > Yeah, in these cases we have something other than the preproc directive itself to indent from. Theo From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Feb 2023 19:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Theodor Thornhill Cc: 61558@debbugs.gnu.org Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.167666237622850 (code B ref 61558); Fri, 17 Feb 2023 19:33:02 +0000 Received: (at 61558) by debbugs.gnu.org; 17 Feb 2023 19:32:56 +0000 Received: from localhost ([127.0.0.1]:41607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pT6TY-0005wU-EV for submit@debbugs.gnu.org; Fri, 17 Feb 2023 14:32:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34248) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pT6TW-0005wF-LT for 61558@debbugs.gnu.org; Fri, 17 Feb 2023 14:32:55 -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 1pT6TR-00038c-3u; Fri, 17 Feb 2023 14:32:49 -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=LMKcc/EWTczPgupsq7Ms0dTtIKJeBmwtCZvKrRkrfN4=; b=jMRtaUeF5OWK 1qJluskK1qmXBV1ID1PKDYqQIBsAy5v1zm3cRd3IKKuas67mDL3OvLN4xzntdQJaP6CBjm6ng+vxd 531R7LJpjQfHVsDLwoUDqGLb+VIuuV81IUupGjTSDQQvDCukeNiy1gOV3o5KO0gTaQCghyi7WCeSl f/pFFsfXULrGB5dO/krsTpcYmcDx3zTJnsAJme/KknjszxDGwXx66rfkS4UJyzM/kAgPEnjAd5Kk4 OkvdhRexjGpRf0hlJ/yTI+tnsjA0C8/DLb7iXdM0clIjOnrFb9qCCxdawNjzIwecRpSpBoMoWcxuM BNyUhQ/rBPmHgjeBQKPpLw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pT6TQ-0004xX-DV; Fri, 17 Feb 2023 14:32:48 -0500 Date: Fri, 17 Feb 2023 21:32:49 +0200 Message-Id: <83zg9cytni.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87cz68p03u.fsf@thornhill.no> (message from Theodor Thornhill on Fri, 17 Feb 2023 20:23:33 +0100) References: <835yc12v7a.fsf@gnu.org> <87cz68p03u.fsf@thornhill.no> X-Spam-Score: -2.3 (--) 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 (---) > From: Theodor Thornhill > Cc: 61558@debbugs.gnu.org > Date: Fri, 17 Feb 2023 20:23:33 +0100 > > #if defined GLYPH_DEBUG && defined ENABLE_CHECKING > /* Increment number of allocated matrices. This count is used > to detect memory leaks. */ > ++glyph_matrix_count; > #endif > > > Is it a correct assuption to think that whatever is inside one of these > if-blocks should indent according to their grand-parents rule? Yes. Basically, a cpp macro definition is like a comment: it disappears when cpp processes it. So, from the language POV, it doesn't exist. > In this case: > > > static struct glyph_matrix * > new_glyph_matrix (struct glyph_pool *pool) > { > struct glyph_matrix *result = xzalloc (sizeof *result); > > #if defined GLYPH_DEBUG && defined ENABLE_CHECKING > /* Increment number of allocated matrices. This count is used > to detect memory leaks. */ > ++glyph_matrix_count; > #endif > > /* Set pool and return. */ > result->pool = pool; > return result; > } > > ++glyph_matrix_count; > > is indented one step from the compound_statement node, right? Sorry: what is the compound_statement node in this case? > > Strangely, in other places indentation does work: lines 1069, 3119. > > > > Yeah, in these cases we have something other than the preproc directive > itself to indent from. Preprocessor directives should have no effect whatsoever on code indentation. From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Feb 2023 19:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 61558@debbugs.gnu.org Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.167666337124586 (code B ref 61558); Fri, 17 Feb 2023 19:50:01 +0000 Received: (at 61558) by debbugs.gnu.org; 17 Feb 2023 19:49:31 +0000 Received: from localhost ([127.0.0.1]:41620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pT6jb-0006OU-04 for submit@debbugs.gnu.org; Fri, 17 Feb 2023 14:49:31 -0500 Received: from out0.migadu.com ([94.23.1.103]:29854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pT6jY-0006OK-Lp for 61558@debbugs.gnu.org; Fri, 17 Feb 2023 14:49:29 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1676663367; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=iyIOUH2NRox1F7gNFW4JL0fw4MW7DwJxOks1KsA7M5Y=; b=Y8Hp3TYJhEkfLT3Qh/pN/CPC23caiVpwq5S7rnMct5e28xwG5t2CXhOd1mo94mHB4Zui0P YiUl0yKjil1troa0ucsBnohV0ENLRWPGvE5yZZDxBhOcA1w4taU5vLpdpHi0MbZTYObB8w pwkZlEOiqJSM8+1gKYybGQol61wqaL2H8mSxo3fd2/XqnRK0nfJMWOE37CN+DUC5c+mS3W 1tIhT8AvFAGAKn0jceUX8HQQbxzWVYxHgsZ1oT2lDJKCfueBUx1TYX5k/xRh6+RpcWhpgD /Be3zhLKRH8YhkGO6jCW9Vda/lTYH8/+TGWxSmXa6ZY0opwip+2me5xxAmTcTA== From: Theodor Thornhill In-Reply-To: <83zg9cytni.fsf@gnu.org> References: <835yc12v7a.fsf@gnu.org> <87cz68p03u.fsf@thornhill.no> <83zg9cytni.fsf@gnu.org> Date: Fri, 17 Feb 2023 20:49:23 +0100 Message-ID: <877cwgoyws.fsf@thornhill.no> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Migadu-Flow: FLOW_OUT X-Spam-Score: -0.7 (/) 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.7 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> From: Theodor Thornhill >> Cc: 61558@debbugs.gnu.org >> Date: Fri, 17 Feb 2023 20:23:33 +0100 >> >> #if defined GLYPH_DEBUG && defined ENABLE_CHECKING >> /* Increment number of allocated matrices. This count is used >> to detect memory leaks. */ >> ++glyph_matrix_count; >> #endif >> >> >> Is it a correct assuption to think that whatever is inside one of these >> if-blocks should indent according to their grand-parents rule? > > Yes. Basically, a cpp macro definition is like a comment: it > disappears when cpp processes it. So, from the language POV, it > doesn't exist. > >> In this case: >> >> >> static struct glyph_matrix * >> new_glyph_matrix (struct glyph_pool *pool) >> { >> struct glyph_matrix *result = xzalloc (sizeof *result); >> >> #if defined GLYPH_DEBUG && defined ENABLE_CHECKING >> /* Increment number of allocated matrices. This count is used >> to detect memory leaks. */ >> ++glyph_matrix_count; >> #endif >> >> /* Set pool and return. */ >> result->pool = pool; >> return result; >> } >> >> ++glyph_matrix_count; >> >> is indented one step from the compound_statement node, right? > > Sorry: what is the compound_statement node in this case? > compound_statement is a {} block. >> > Strangely, in other places indentation does work: lines 1069, 3119. >> > >> >> Yeah, in these cases we have something other than the preproc directive >> itself to indent from. > > Preprocessor directives should have no effect whatsoever on code > indentation. Right, thanks. Can you test this patch? It seems to work for me, but I'm no C expert. Theo --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Cleanup-preproc-indent-for-c-ts-mode.patch >From 30387d0a115f78b2184632e4f3bca6ee3a32417f Mon Sep 17 00:00:00 2001 From: Theodor Thornhill Date: Fri, 17 Feb 2023 20:46:19 +0100 Subject: [PATCH] Cleanup preproc indent for c-ts-mode * lisp/progmodes/c-ts-mode.el (c-ts-mode--indent-styles): Make sure we indent to grand-parent if inside an #ifdef...#endif block. If grandparent is root node, then don't indent one step. --- lisp/progmodes/c-ts-mode.el | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el index a60c464093..54b1482403 100644 --- a/lisp/progmodes/c-ts-mode.el +++ b/lisp/progmodes/c-ts-mode.el @@ -246,13 +246,13 @@ c-ts-mode--indent-styles ((match nil "do_statement" "body") parent-bol c-ts-mode-indent-offset) ((match nil "for_statement" "body") parent-bol c-ts-mode-indent-offset) - ((match "preproc_ifdef" "compound_statement") point-min 0) - ((match "#endif" "preproc_ifdef") point-min 0) - ((match "preproc_if" "compound_statement") point-min 0) - ((match "#endif" "preproc_if") point-min 0) - ((match "preproc_function_def" "compound_statement") point-min 0) + ((node-is "preproc") point-min 0) + ((node-is "#endif") point-min 0) ((match "preproc_call" "compound_statement") point-min 0) + ((n-p-gp nil "preproc" "translation_unit") point-min 0) + ((parent-is "preproc") grand-parent c-ts-mode-indent-offset) + ((parent-is "function_definition") parent-bol 0) ((parent-is "conditional_expression") first-sibling 0) ((parent-is "assignment_expression") parent-bol c-ts-mode-indent-offset) -- 2.34.1 --=-=-=-- From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Feb 2023 09:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Theodor Thornhill Cc: 61558@debbugs.gnu.org Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.167671403724359 (code B ref 61558); Sat, 18 Feb 2023 09:54:02 +0000 Received: (at 61558) by debbugs.gnu.org; 18 Feb 2023 09:53:57 +0000 Received: from localhost ([127.0.0.1]:42506 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTJum-0006Ko-Ie for submit@debbugs.gnu.org; Sat, 18 Feb 2023 04:53:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36116) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTJuk-0006KV-5i for 61558@debbugs.gnu.org; Sat, 18 Feb 2023 04:53:55 -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 1pTJue-0007ih-E6; Sat, 18 Feb 2023 04:53:48 -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=9RQsaQjUl/a8Vs/L10NHXx0zRg4l1bkFwA9KLvgJWQI=; b=fTrRsW9DaP+P M9hnFO7teHNRpxDKo8gCoXk/zCuEjETEHBl9vllL2mWyG7fwV4wuAquRQO9ijvIF7cdljbWB5xQ2/ DdycHGvI6jqjB4KPdpCmzvTtVtBB+vrUmKsjKRoaAqzU05zoOLe/nJY5mrsuyo95C8XVQ2CZhZQKZ occVNTZ5ecHwRL2jutxC+PqeB6PSU3iiS5SzdFfu4jpw5oAB3h8RiXe3cABHgy6O0yf9jKriA6xw9 G4cFNbVRCrlJZTyL8KeEzv/5AfwoUNaHZeYDTRk9EK0DI9Dn0HRYAW2HgZs2mSFm4wSDwbwie+PEo QI/TSq152NdIeLUXihAYCg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pTJud-0007Jk-LQ; Sat, 18 Feb 2023 04:53:47 -0500 Date: Sat, 18 Feb 2023 11:53:49 +0200 Message-Id: <83ilfzz4cy.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <877cwgoyws.fsf@thornhill.no> (message from Theodor Thornhill on Fri, 17 Feb 2023 20:49:23 +0100) References: <835yc12v7a.fsf@gnu.org> <87cz68p03u.fsf@thornhill.no> <83zg9cytni.fsf@gnu.org> <877cwgoyws.fsf@thornhill.no> X-Spam-Score: -2.3 (--) 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 (---) > From: Theodor Thornhill > Cc: 61558@debbugs.gnu.org > Date: Fri, 17 Feb 2023 20:49:23 +0100 > > Can you test this patch? It seems to work for me, but I'm no C expert. Thanks, this is much better. However, the handling of #if (as opposed to #ifdef) is still incorrect. For example, go to the end of line 3376 of dispnew.c and type RET: point goes to column zero, not column 2. If you convert "#if" to #ifdef", the behavior becomes correct. Same problem exists with #elif. Doesn't tree-sitter grammar consider #if and #elif preprocessor nodes? Also, there's a problem with #define in the middle of code. For example, here: /* Put a `display' property on the string for the captions to display, put a `menu_item' property on tab-bar items with a value that is the index of the item in F's tab-bar item vector. */ for (i = 0; i < f->n_tab_bar_items; ++i) { #define PROP(IDX) \ AREF (f->tab_bar_items, i * TAB_BAR_ITEM_NSLOTS + (IDX)) caption = Fcopy_sequence (PROP (TAB_BAR_ITEM_CAPTION)); <<<<<<<<<< /* Put a `display' text property on the string for the caption to display. Put a `menu-item' property on the string that gives the start of this item's properties in the tab-bar items vector. */ AUTO_LIST2 (props, Qmenu_item, make_fixnum (i * TAB_BAR_ITEM_NSLOTS)); Fadd_text_properties (make_fixnum (0), make_fixnum (SCHARS (caption)), props, caption); f->desired_tab_bar_string = concat2 (f->desired_tab_bar_string, caption); #undef PROP <<<<<<<<<<<<<<<<<<<< } Typing RET at the end of the two marked lines goes to column zero instead of the expected non-zero column. So it sounds like #define and #undef are also not handled correctly yet. From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Feb 2023 21:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 61558@debbugs.gnu.org Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.16767547159297 (code B ref 61558); Sat, 18 Feb 2023 21:12:02 +0000 Received: (at 61558) by debbugs.gnu.org; 18 Feb 2023 21:11:55 +0000 Received: from localhost ([127.0.0.1]:45080 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTUUt-0002Pt-Er for submit@debbugs.gnu.org; Sat, 18 Feb 2023 16:11:55 -0500 Received: from out0.migadu.com ([94.23.1.103]:21681) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTUUr-0002Pl-JA for 61558@debbugs.gnu.org; Sat, 18 Feb 2023 16:11:54 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1676754711; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xqpV5heMFd7UfUlzyZrOBBHBLHjsChcHTaI6+pxMTKw=; b=xx8i/ET/zParQ6Z6VK5GnP5ElKkkLo0cfv1OIv0hJF3a60u3SFNjaftN0ZRnHyAv5EcFV7 SSuK+4gTf+GDelirkNmfFSMTpA6EbgQgczNE9XVAqo+Io0Zyotl9C4bF6POaGPRrtVeo+i 0tDueNldfZfwr/J28tdQHvw+79gF5kEdw5/KhMWfFYcbQKMHT7uJhuI1rWUtb09Icb8fON 132gwSWnXO8hCcb2lVQQU2FV7gCa3c+HumLsvN+L5zzuED91EtMjSyd7mFGMChOhnI6kaQ eSRoGvDZZjz94CAhrZwyLDqz96+9TDgog7UPNRk1PpCT239XrgQP1McKVY+4cg== From: Theodor Thornhill In-Reply-To: <83ilfzz4cy.fsf@gnu.org> References: <835yc12v7a.fsf@gnu.org> <87cz68p03u.fsf@thornhill.no> <83zg9cytni.fsf@gnu.org> <877cwgoyws.fsf@thornhill.no> <83ilfzz4cy.fsf@gnu.org> Date: Sat, 18 Feb 2023 22:11:49 +0100 Message-ID: <87bklq65m2.fsf@thornhill.no> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Spam-Score: -0.7 (/) 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.7 (-) Eli Zaretskii writes: >> From: Theodor Thornhill >> Cc: 61558@debbugs.gnu.org >> Date: Fri, 17 Feb 2023 20:49:23 +0100 >> >> Can you test this patch? It seems to work for me, but I'm no C expert. > > Thanks, this is much better. However, the handling of #if (as opposed > to #ifdef) is still incorrect. For example, go to the end of line > 3376 of dispnew.c and type RET: point goes to column zero, not column > 2. If you convert "#if" to #ifdef", the behavior becomes correct. > Same problem exists with #elif. > > Doesn't tree-sitter grammar consider #if and #elif preprocessor nodes? It seems we are at the mercy of this[0] issue here, in all the cases you've described. > > Also, there's a problem with #define in the middle of code. For > example, here: > > /* Put a `display' property on the string for the captions to display, > put a `menu_item' property on tab-bar items with a value that > is the index of the item in F's tab-bar item vector. */ > for (i = 0; i < f->n_tab_bar_items; ++i) > { > #define PROP(IDX) \ > AREF (f->tab_bar_items, i * TAB_BAR_ITEM_NSLOTS + (IDX)) > > caption = Fcopy_sequence (PROP (TAB_BAR_ITEM_CAPTION)); <<<<<<<<<< > > /* Put a `display' text property on the string for the caption to > display. Put a `menu-item' property on the string that gives > the start of this item's properties in the tab-bar items > vector. */ > AUTO_LIST2 (props, Qmenu_item, make_fixnum (i * TAB_BAR_ITEM_NSLOTS)); > > Fadd_text_properties (make_fixnum (0), make_fixnum (SCHARS (caption)), > props, caption); > > f->desired_tab_bar_string = > concat2 (f->desired_tab_bar_string, caption); > > #undef PROP <<<<<<<<<<<<<<<<<<<< > } > > Typing RET at the end of the two marked lines goes to column zero > instead of the expected non-zero column. So it sounds like #define > and #undef are also not handled correctly yet. Yeah, luckily it indents correctly after you start to type. I'll try to see if I can make some specific handling for this. Theo [0]: https://github.com/tree-sitter/tree-sitter-c/issues/97 From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Feb 2023 21:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 61558@debbugs.gnu.org Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.167675581211001 (code B ref 61558); Sat, 18 Feb 2023 21:31:02 +0000 Received: (at 61558) by debbugs.gnu.org; 18 Feb 2023 21:30:12 +0000 Received: from localhost ([127.0.0.1]:45090 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTUmZ-0002rM-HX for submit@debbugs.gnu.org; Sat, 18 Feb 2023 16:30:12 -0500 Received: from out0.migadu.com ([94.23.1.103]:30617) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTUmW-0002qo-EC for 61558@debbugs.gnu.org; Sat, 18 Feb 2023 16:30:09 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1676755807; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vYrRx/WxKDHk8hrSala50ZuyYhaIrxh3Q8J2bb1cbvQ=; b=FyYN+bBBqIqXTbtHu1NDQ68r++SNuhsJcPEkgkcJO3uN+tSTfkCqhpQvcd6TvktYc2JITw UUI4XBQaWlLzWPmOu/HtenNrhol/m2qQzePZoZtPOAbEaoqqTDS6oyeTH36WTQHDvCfep7 6iHFv7CuLoWZfGvZuvL3BBPcnKlSslOZDnFahaaWHIl5IcCrPhzrqkGLFpayuewfszUY/2 OhGXznxIhesF3SLvBsBiyiYZNocrkYJxndurNZDjQKv1jScMgTsASpLLrM6IL2cf4MGcCh 4lNKF1wnXUiWqVZzVd89Nwg4Yp4+dXzw5MjCMH6W843U6oP6Khn8zbFcKR7z4g== From: Theodor Thornhill In-Reply-To: <87bklq65m2.fsf@thornhill.no> References: <835yc12v7a.fsf@gnu.org> <87cz68p03u.fsf@thornhill.no> <83zg9cytni.fsf@gnu.org> <877cwgoyws.fsf@thornhill.no> <83ilfzz4cy.fsf@gnu.org> <87bklq65m2.fsf@thornhill.no> Date: Sat, 18 Feb 2023 22:30:06 +0100 Message-ID: <878rgu64rl.fsf@thornhill.no> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Migadu-Flow: FLOW_OUT X-Spam-Score: -0.7 (/) 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.7 (-) --=-=-= Content-Type: text/plain Theodor Thornhill writes: > Eli Zaretskii writes: > >>> From: Theodor Thornhill >>> Cc: 61558@debbugs.gnu.org >>> Date: Fri, 17 Feb 2023 20:49:23 +0100 >>> >>> Can you test this patch? It seems to work for me, but I'm no C expert. >> >> Thanks, this is much better. However, the handling of #if (as opposed >> to #ifdef) is still incorrect. For example, go to the end of line >> 3376 of dispnew.c and type RET: point goes to column zero, not column >> 2. If you convert "#if" to #ifdef", the behavior becomes correct. >> Same problem exists with #elif. >> >> Doesn't tree-sitter grammar consider #if and #elif preprocessor nodes? > > It seems we are at the mercy of this[0] issue here, in all the cases > you've described. > >> >> Also, there's a problem with #define in the middle of code. For >> example, here: >> >> /* Put a `display' property on the string for the captions to display, >> put a `menu_item' property on tab-bar items with a value that >> is the index of the item in F's tab-bar item vector. */ >> for (i = 0; i < f->n_tab_bar_items; ++i) >> { >> #define PROP(IDX) \ >> AREF (f->tab_bar_items, i * TAB_BAR_ITEM_NSLOTS + (IDX)) >> >> caption = Fcopy_sequence (PROP (TAB_BAR_ITEM_CAPTION)); <<<<<<<<<< >> >> /* Put a `display' text property on the string for the caption to >> display. Put a `menu-item' property on the string that gives >> the start of this item's properties in the tab-bar items >> vector. */ >> AUTO_LIST2 (props, Qmenu_item, make_fixnum (i * TAB_BAR_ITEM_NSLOTS)); >> >> Fadd_text_properties (make_fixnum (0), make_fixnum (SCHARS (caption)), >> props, caption); >> >> f->desired_tab_bar_string = >> concat2 (f->desired_tab_bar_string, caption); >> >> #undef PROP <<<<<<<<<<<<<<<<<<<< >> } >> >> Typing RET at the end of the two marked lines goes to column zero >> instead of the expected non-zero column. So it sounds like #define >> and #undef are also not handled correctly yet. > > Yeah, luckily it indents correctly after you start to type. I'll try to > see if I can make some specific handling for this. > > Theo > Scratch that. Can you test this for me? I think I got it. Theo --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Cleanup-preproc-indent-for-c-ts-mode.patch >From ba9fc0542351506e2271a5edd47f00feb2163245 Mon Sep 17 00:00:00 2001 From: Theodor Thornhill Date: Fri, 17 Feb 2023 20:46:19 +0100 Subject: [PATCH] Cleanup preproc indent for c-ts-mode * lisp/progmodes/c-ts-mode.el (c-ts-mode--indent-styles): Make sure we indent to grand-parent if inside an #ifdef...#endif block. If grandparent is root node, then don't indent one step. --- lisp/progmodes/c-ts-mode.el | 11 ++++++----- lisp/treesit.el | 5 +++++ 2 files changed, 11 insertions(+), 5 deletions(-) diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el index 05875e9267..9c28fc4ad4 100644 --- a/lisp/progmodes/c-ts-mode.el +++ b/lisp/progmodes/c-ts-mode.el @@ -265,13 +265,14 @@ c-ts-mode--indent-styles ((match nil "do_statement" "body") parent-bol c-ts-mode-indent-offset) ((match nil "for_statement" "body") parent-bol c-ts-mode-indent-offset) - ((match "preproc_ifdef" "compound_statement") point-min 0) - ((match "#endif" "preproc_ifdef") point-min 0) - ((match "preproc_if" "compound_statement") point-min 0) - ((match "#endif" "preproc_if") point-min 0) - ((match "preproc_function_def" "compound_statement") point-min 0) + ((node-is "preproc") point-min 0) + ((node-is "#endif") point-min 0) ((match "preproc_call" "compound_statement") point-min 0) + ((n-p-gp nil "preproc" "translation_unit") point-min 0) + ((n-p-gp nil "\n" "preproc") great-grand-parent c-ts-mode-indent-offset) + ((parent-is "preproc") grand-parent c-ts-mode-indent-offset) + ((parent-is "function_definition") parent-bol 0) ((parent-is "conditional_expression") first-sibling 0) ((parent-is "assignment_expression") parent-bol c-ts-mode-indent-offset) diff --git a/lisp/treesit.el b/lisp/treesit.el index 09531b838a..be864d8f1f 100644 --- a/lisp/treesit.el +++ b/lisp/treesit.el @@ -1204,6 +1204,11 @@ treesit-simple-indent-presets (cons 'grand-parent (lambda (_n parent &rest _) (treesit-node-start (treesit-node-parent parent)))) + (cons 'great-grand-parent + (lambda (_n parent &rest _) + (treesit-node-start + (treesit-node-parent + (treesit-node-parent parent))))) (cons 'parent-bol (lambda (_n parent &rest _) (save-excursion (goto-char (treesit-node-start parent)) -- 2.34.1 --=-=-= Content-Type: text/plain > > [0]: https://github.com/tree-sitter/tree-sitter-c/issues/97 --=-=-=-- From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Feb 2023 07:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Theodor Thornhill Cc: 61558@debbugs.gnu.org Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.167679254310699 (code B ref 61558); Sun, 19 Feb 2023 07:43:02 +0000 Received: (at 61558) by debbugs.gnu.org; 19 Feb 2023 07:42:23 +0000 Received: from localhost ([127.0.0.1]:45588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTeL1-0002mU-Ag for submit@debbugs.gnu.org; Sun, 19 Feb 2023 02:42:23 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52994) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTeKy-0002mI-VF for 61558@debbugs.gnu.org; Sun, 19 Feb 2023 02:42:21 -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 1pTeKt-0000D2-8D; Sun, 19 Feb 2023 02:42:15 -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=eCyRx9sTGQ4x27cPWYTdcqWKtcnLtwB9ZvSGwhP5hlQ=; b=XGICo8j++vDT CBSSN/6jwOsCfgrNLWT+ZiADguvXUtGAzaNVl0Qe/shxrGYFX14wkni9QAsqHtzNW78KI03NnlVnl DaIBAlPfkIUQXOJ8lj/kwDmMJNnhBP0cHX/sBBb45F5QOu4BF30H7NB4lsqE/2AggGby6HILWArO1 uCgsG3wQUs72UWTG7AYGwlNDOmg/hW78WO5oKub5QVruXn5MBGX4y1H0LIxN5TnhZ6oXQKvIDoT8v U7sj6waWFbw27McbJKcn2sYGtiwgfe3sAClPmUPD4EjQygW0PemRHEJGLIrUvgLEctaY6zALo2+Mn LJQjIwh4+LwzmDysMhEdDw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pTeKs-0004jy-MZ; Sun, 19 Feb 2023 02:42:15 -0500 Date: Sun, 19 Feb 2023 09:42:19 +0200 Message-Id: <83bklqxfs4.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <878rgu64rl.fsf@thornhill.no> (message from Theodor Thornhill on Sat, 18 Feb 2023 22:30:06 +0100) References: <835yc12v7a.fsf@gnu.org> <87cz68p03u.fsf@thornhill.no> <83zg9cytni.fsf@gnu.org> <877cwgoyws.fsf@thornhill.no> <83ilfzz4cy.fsf@gnu.org> <87bklq65m2.fsf@thornhill.no> <878rgu64rl.fsf@thornhill.no> X-Spam-Score: -2.3 (--) 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 (---) > From: Theodor Thornhill > Cc: 61558@debbugs.gnu.org > Date: Sat, 18 Feb 2023 22:30:06 +0100 > > >> Typing RET at the end of the two marked lines goes to column zero > >> instead of the expected non-zero column. So it sounds like #define > >> and #undef are also not handled correctly yet. > > > > Yeah, luckily it indents correctly after you start to type. I'll try to > > see if I can make some specific handling for this. > > > > Theo > > > > Scratch that. Can you test this for me? I think I got it. Thanks, this seems to work better. Some problems still remain, though. Line 807 of dispnew.c: #if defined (HAVE_WINDOW_SYSTEM) && ! defined (HAVE_EXT_TOOL_BAR) /* Clear the matrix of the tool-bar window, if any. */ if (WINDOWP (f->tool_bar_window)) <<<<<<<<<<<<<<<<<< clear_glyph_matrix (XWINDOW (f->tool_bar_window)->current_matrix); #endif Type RET at the end, then type '{' and RET. The '{' gets indented correctly, but there's no additional two-column indent after RET that follows '{'. RET after preprocessor directives outside of functions indents by 2 columns. For example, here: #if 0 /* Swap glyphs between two glyph rows A and B. This exchanges glyph contents, i.e. glyph structure contents are exchanged between A and B without changing glyph pointers in A and B. */ If you type RET after "#if 0", point goes to column 2, not zero. Interestingly, if you type RET at the end of the last line of the following comment, point goes to column zero, as expected. Line 1357 of dispnew.c: static void free_glyph_pool (struct glyph_pool *pool) { if (pool) { #if defined GLYPH_DEBUG && defined ENABLE_CHECKING <<<<<<<<<<<<<<< /* More freed than allocated? */ --glyph_pool_count; eassert (glyph_pool_count >= 0); #endif xfree (pool->glyphs); xfree (pool); } } Type RET at the end of the indicated line: point goes to column 6, as expected. But if you then type "{ RET", point gets indented by 4 columns, not by 2. And even typing a semi-colon afterwards doesn't fix the indentation. Similarly here: static void adjust_frame_glyphs_for_window_redisplay (struct frame *f) { eassert (FRAME_WINDOW_P (f) && FRAME_LIVE_P (f)); /* Allocate/reallocate window matrices. */ allocate_matrices_for_window_redisplay (XWINDOW (FRAME_ROOT_WINDOW (f))); #if defined (HAVE_X_WINDOWS) && ! defined (USE_X_TOOLKIT) && ! defined (USE_GTK) /* Allocate/ reallocate matrices of the dummy window used to display the menu bar under X when no X toolkit support is available. */ { <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< /* Allocate a dummy window if not already done. */ struct window *w; if (NILP (f->menu_bar_window)) The indicated line is 2166 in dispnew.c. If you type RET there, point will be indented to column 6, not 4 as expected. And if you type RET at the end of the following comment line, not only will point be over-indented, but the comment itself will also be reindented incorrectly. Anyway, this works much better than the original code, and I saw no regressions, so I think you should install this. Perhaps consider adding comments explaining any tricky parts of handling this, so that future hackers will know what to do and what to avoid. Bonus points for adding tests for this, so that we don't easily regress in the future. Thanks! From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Feb 2023 07:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Theodor Thornhill Cc: 61558@debbugs.gnu.org Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.167679263310856 (code B ref 61558); Sun, 19 Feb 2023 07:44:01 +0000 Received: (at 61558) by debbugs.gnu.org; 19 Feb 2023 07:43:53 +0000 Received: from localhost ([127.0.0.1]:45596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTeMT-0002p2-4J for submit@debbugs.gnu.org; Sun, 19 Feb 2023 02:43:53 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49518) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTeMR-0002oo-9K for 61558@debbugs.gnu.org; Sun, 19 Feb 2023 02:43:51 -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 1pTeMM-0000Jt-0g; Sun, 19 Feb 2023 02:43:46 -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=11ID3HfvkAnqONdXVHcZW6ETssYJyJ16UNMYjleW4L8=; b=gPSrNonoDzZA /90moaMR8+cd+8ulsFUx9HmVwhl34zcXX+uqV8CkIt7foJ3jqn32zEeMvEU476D1BaF3MqaeFf+tn Uhfo5MdK/RJVp/Aef5kvOlESoeSM8HnPulyz4VDs5aawvPUe8V420ekKx+UW9Az86VjjnSXDFiN0M xsFUaLSEWTYyXL2hrHfifunAZxMDAVUXK/3K22IMKnF2iXcyr9W3B+XM+4BZJoNklGf32tDeZydo/ Osb5878R7tKI1LWqpkc81VmHbSi2z1s8xO2zedx3yIad/gS+e7RO/6iDx7iVUzERsZUCTa2mzCqRJ 1/dpaRN4H1ZbYkIWc+UbxQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pTeML-0004o0-5x; Sun, 19 Feb 2023 02:43:45 -0500 Date: Sun, 19 Feb 2023 09:43:49 +0200 Message-Id: <83a61axfpm.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87bklq65m2.fsf@thornhill.no> (message from Theodor Thornhill on Sat, 18 Feb 2023 22:11:49 +0100) References: <835yc12v7a.fsf@gnu.org> <87cz68p03u.fsf@thornhill.no> <83zg9cytni.fsf@gnu.org> <877cwgoyws.fsf@thornhill.no> <83ilfzz4cy.fsf@gnu.org> <87bklq65m2.fsf@thornhill.no> X-Spam-Score: -2.3 (--) 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 (---) > From: Theodor Thornhill > Cc: 61558@debbugs.gnu.org > Date: Sat, 18 Feb 2023 22:11:49 +0100 > > > Doesn't tree-sitter grammar consider #if and #elif preprocessor nodes? > > It seems we are at the mercy of this[0] issue here, in all the cases > you've described. That issue is about #include, not #if. Is that related? From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Feb 2023 08:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 61558@debbugs.gnu.org Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.167679367112895 (code B ref 61558); Sun, 19 Feb 2023 08:02:02 +0000 Received: (at 61558) by debbugs.gnu.org; 19 Feb 2023 08:01:11 +0000 Received: from localhost ([127.0.0.1]:45610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTedD-0003Lv-HJ for submit@debbugs.gnu.org; Sun, 19 Feb 2023 03:01:11 -0500 Received: from out0.migadu.com ([94.23.1.103]:18831) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTed9-0003Lh-Ei for 61558@debbugs.gnu.org; Sun, 19 Feb 2023 03:01:10 -0500 Date: Sun, 19 Feb 2023 09:01:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1676793663; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ImElK7g5wuplsV3xTUPqgOq0nv3nnuiGE+X3h5LTcoI=; b=PXmLfgdNXsr4EaCdzul7P9PD1+u6g7UEjVfhcDIn6kLKbVZEzczmxTsokXecBGW2ijrd1r ABvFVQIUV3FpibL7wpcuUrYzbup1MP8JgugErEfZKqYhAvOygg6lW8QMaukhZjzkL0cwX0 6+Rv660BaQyntdUFK7S35GPkrsBwWkx1uN2aeuK1GVm9v/lQd7GlzOcnG36x61jsOkhDu5 peOsmulDOrYaw7gV8+Ku1+gAPWvC25mf30Dh719VaElhLLw6PAFeXrauvigvggoZu3/yo5 jL/x1WRJeDoS+t5yxDThG3+h+3Oq86ceKlLGz4yYgnobuRa3aCkAg+Cwry9V9Q== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill In-Reply-To: <83a61axfpm.fsf@gnu.org> References: <835yc12v7a.fsf@gnu.org> <87cz68p03u.fsf@thornhill.no> <83zg9cytni.fsf@gnu.org> <877cwgoyws.fsf@thornhill.no> <83ilfzz4cy.fsf@gnu.org> <87bklq65m2.fsf@thornhill.no> <83a61axfpm.fsf@gnu.org> Message-ID: <224D8CBD-F363-4762-8C1F-A777B6601E6A@thornhill.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Spam-Score: -0.7 (/) 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.7 (-) On 19 February 2023 08:43:49 CET, Eli Zaretskii wrote: >> From: Theodor Thornhill >> Cc: 61558@debbugs=2Egnu=2Eorg >> Date: Sat, 18 Feb 2023 22:11:49 +0100 >>=20 >> > Doesn't tree-sitter grammar consider #if and #elif preprocessor nodes= ? >>=20 >> It seems we are at the mercy of this[0] issue here, in all the cases >> you've described=2E > >That issue is about #include, not #if=2E Is that related? Yeah, because all preprocs add these \n nodes that are a bit hard to accou= nt for at they are anonymous, and not declared as a legal node in the gramm= ar=2E I think they are just there because some tokenizing bug=2E From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Feb 2023 09:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 61558@debbugs.gnu.org Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.167679845621333 (code B ref 61558); Sun, 19 Feb 2023 09:21:02 +0000 Received: (at 61558) by debbugs.gnu.org; 19 Feb 2023 09:20:56 +0000 Received: from localhost ([127.0.0.1]:45673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTfsO-0005Y0-5b for submit@debbugs.gnu.org; Sun, 19 Feb 2023 04:20:56 -0500 Received: from out2.migadu.com ([188.165.223.204]:31156) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTfsM-0005Xr-6L for 61558@debbugs.gnu.org; Sun, 19 Feb 2023 04:20:55 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1676798452; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3de4De7hm8Sx755FXCjB5RbqrkTtIPSmFb6baGR92/s=; b=rOh0ih9hhZFfDVg1/JcERrLLvENT5f/5fIODh602/hOrUNvd5+jGnkmVOD+OUi65z3VhcH aeps+TfOuDQ65Ce+sUnHb2dxm7ZDjBOsl6v76FBhusPYceNePxjFuJ3i3Ak8958C+t5DNA 4qseQMIaZc5e2pVyxbxiyg9dVQRBcdLYLgFJkbHbc8Dc92uXojnmNSbUtoeTLm8m1UAJhB buTQ0/33jvyFCcGJatvGUS2dvMa8+Awt5uFDCJxG4PvCC/wjzMhAnKZ/cRPFh74/eVzRCL tjf4IN3HcDw1+LqDQA6vdOgJmQOBLRDV9fd+ksFFR8kGGGeF7xdasI7wcX+TZQ== From: Theodor Thornhill In-Reply-To: <83bklqxfs4.fsf@gnu.org> References: <835yc12v7a.fsf@gnu.org> <87cz68p03u.fsf@thornhill.no> <83zg9cytni.fsf@gnu.org> <877cwgoyws.fsf@thornhill.no> <83ilfzz4cy.fsf@gnu.org> <87bklq65m2.fsf@thornhill.no> <878rgu64rl.fsf@thornhill.no> <83bklqxfs4.fsf@gnu.org> Date: Sun, 19 Feb 2023 10:20:50 +0100 Message-ID: <87v8jyhuz1.fsf@thornhill.no> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Spam-Score: -0.0 (/) 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 (-) Eli Zaretskii writes: >> From: Theodor Thornhill >> Cc: 61558@debbugs.gnu.org >> Date: Sat, 18 Feb 2023 22:30:06 +0100 >> >> >> Typing RET at the end of the two marked lines goes to column zero >> >> instead of the expected non-zero column. So it sounds like #define >> >> and #undef are also not handled correctly yet. >> > >> > Yeah, luckily it indents correctly after you start to type. I'll try to >> > see if I can make some specific handling for this. >> > >> > Theo >> > >> >> Scratch that. Can you test this for me? I think I got it. > > Thanks, this seems to work better. Some problems still remain, > though. > > Line 807 of dispnew.c: > > #if defined (HAVE_WINDOW_SYSTEM) && ! defined (HAVE_EXT_TOOL_BAR) > /* Clear the matrix of the tool-bar window, if any. */ > if (WINDOWP (f->tool_bar_window)) <<<<<<<<<<<<<<<<<< > clear_glyph_matrix (XWINDOW (f->tool_bar_window)->current_matrix); > #endif > > Type RET at the end, then type '{' and RET. The '{' gets indented > correctly, but there's no additional two-column indent after RET that > follows '{'. This is due to how 'c-ts-common-statement-offset' works, which seems to assume balanced pairs. I think this is "unrelated" to this bug. > > RET after preprocessor directives outside of functions indents by 2 > columns. For example, here: > > #if 0 > /* Swap glyphs between two glyph rows A and B. This exchanges glyph > contents, i.e. glyph structure contents are exchanged between A and > B without changing glyph pointers in A and B. */ > > If you type RET after "#if 0", point goes to column 2, not zero. > Interestingly, if you type RET at the end of the last line of the > following comment, point goes to column zero, as expected. This one I'll fix. > > Line 1357 of dispnew.c: > > static void > free_glyph_pool (struct glyph_pool *pool) > { > if (pool) > { > #if defined GLYPH_DEBUG && defined ENABLE_CHECKING <<<<<<<<<<<<<<< > /* More freed than allocated? */ > --glyph_pool_count; > eassert (glyph_pool_count >= 0); > #endif > xfree (pool->glyphs); > xfree (pool); > } > } > > Type RET at the end of the indicated line: point goes to column 6, as > expected. But if you then type "{ RET", point gets indented by 4 > columns, not by 2. And even typing a semi-colon afterwards doesn't > fix the indentation. > > Similarly here: > > static void > adjust_frame_glyphs_for_window_redisplay (struct frame *f) > { > eassert (FRAME_WINDOW_P (f) && FRAME_LIVE_P (f)); > > /* Allocate/reallocate window matrices. */ > allocate_matrices_for_window_redisplay (XWINDOW (FRAME_ROOT_WINDOW (f))); > > #if defined (HAVE_X_WINDOWS) && ! defined (USE_X_TOOLKIT) && ! defined (USE_GTK) > /* Allocate/ reallocate matrices of the dummy window used to display > the menu bar under X when no X toolkit support is available. */ > { <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > /* Allocate a dummy window if not already done. */ > struct window *w; > if (NILP (f->menu_bar_window)) > > The indicated line is 2166 in dispnew.c. If you type RET there, point > will be indented to column 6, not 4 as expected. And if you type RET > at the end of the following comment line, not only will point be > over-indented, but the comment itself will also be reindented > incorrectly. > > Anyway, this works much better than the original code, and I saw no > regressions, so I think you should install this. Perhaps consider > adding comments explaining any tricky parts of handling this, so that > future hackers will know what to do and what to avoid. Bonus points > for adding tests for this, so that we don't easily regress in the > future. > Great! Will do :-) > Thanks! No problem! From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif References: <835yc12v7a.fsf@gnu.org> In-Reply-To: <835yc12v7a.fsf@gnu.org> Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Feb 2023 04:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Theodor Thornhill Cc: Eli Zaretskii , 61558@debbugs.gnu.org Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.167729942215550 (code B ref 61558); Sat, 25 Feb 2023 04:31:01 +0000 Received: (at 61558) by debbugs.gnu.org; 25 Feb 2023 04:30:22 +0000 Received: from localhost ([127.0.0.1]:38766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVmCU-00042k-6H for submit@debbugs.gnu.org; Fri, 24 Feb 2023 23:30:22 -0500 Received: from mail-pj1-f54.google.com ([209.85.216.54]:39628) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVmCS-00042V-Jj for 61558@debbugs.gnu.org; Fri, 24 Feb 2023 23:30:21 -0500 Received: by mail-pj1-f54.google.com with SMTP id 6-20020a17090a190600b00237c5b6ecd7so332120pjg.4 for <61558@debbugs.gnu.org>; Fri, 24 Feb 2023 20:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=rq/oQd9CpKU1aW1dQQ4nOruUHKdiCp8j28HSZl3KhRo=; b=A1YLYZ6QPvknAid9vk14j7C+fjNHW4Nqzi/InXUHJxgsyzH1b/LfJlATENMqZ5bwUG r9tPGMImpSNiBQh3cqbKD19/lhJ2Vs9oT9FAMLv5l35qLf83k+QypIbkdyOBX6yta97N V0RVWZYnWEetll9WETqyBoSo+zznUqk1FW8tIe2/GkJQHzl0QN13cUK7qbtD+0LvQBYe bFFbjdEEwvR0Ayb3U9/YZH2ctqBkzDxVfNLlrmSKufN/MLsrydu2DRFAcDCFXaeWuKBx cInHzR9SYWWo509CoBRZmsW+EkE2nceWJI4XXkGhUne76mT6L0M2xFpdr6TU6r/PPU9M cobQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rq/oQd9CpKU1aW1dQQ4nOruUHKdiCp8j28HSZl3KhRo=; b=DjMM1OJWEmbsscJOAW/h19iQGFIfrXGVsDEWJjWOw8+aJ0ZAAUPrEuARH2zwYWL0Ow 7Iv4fOnqPlUoG/7jkDowRQz5lvRGUWOJwHQ/SPs/lrJ1Goz0maMyiyTwi5slLJUSXWm1 8bHAxJPYOIUzFoAhA17VFRCL22bd2M6WrRNG7lZpKLRCoxaa6yWT8/mJeAFu/k5o14gr eyGstFEyQvfkDm3R8chm/TcJLHaafbAy0MmGt0MkhbTHV/Ws/b6vUIesb1SR58y9RZWb a/Yew/JRStoi/z9eXyQjeVXz2+P8oXgCIYz2jOL2frB4Z5B2jQvkiNanVqGcdcnYg7ZK VrKg== X-Gm-Message-State: AO0yUKUmwHRVo9UbPkO7+xanmvJvtIW7+8Yhp3XmtO833L+DXwwVEm1D lQ56MrWUqMQiOw/fvylP+DE= X-Google-Smtp-Source: AK7set9oesA3+4uBl8re4KlhEYBBmiUmEJFvq0BCwbqUrhwkf9YkuQZv1yUJD7RecqQAH11VbUMxNw== X-Received: by 2002:a17:902:ea07:b0:19a:887d:98ac with SMTP id s7-20020a170902ea0700b0019a887d98acmr21910567plg.46.1677299414459; Fri, 24 Feb 2023 20:30:14 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id j63-20020a638b42000000b005030113f46dsm282833pge.37.2023.02.24.20.30.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2023 20:30:14 -0800 (PST) From: Yuan Fu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Message-Id: Date: Fri, 24 Feb 2023 20:30:02 -0800 X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spam-Score: 0.0 (/) 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 (-) Theodor Thornhill writes: > Eli Zaretskii writes: > >>> From: Theodor Thornhill >>> Cc: 61558@debbugs.gnu.org >>> Date: Sat, 18 Feb 2023 22:30:06 +0100 >>>=20 >>> >> Typing RET at the end of the two marked lines goes to column zero >>> >> instead of the expected non-zero column. So it sounds like = #define >>> >> and #undef are also not handled correctly yet. >>> > >>> > Yeah, luckily it indents correctly after you start to type. I'll = try to >>> > see if I can make some specific handling for this. >>> > >>> > Theo >>> > >>>=20 >>> Scratch that. Can you test this for me? I think I got it. >> >> Thanks, this seems to work better. Some problems still remain, >> though. >> >> Line 807 of dispnew.c: >> >> #if defined (HAVE_WINDOW_SYSTEM) && ! defined (HAVE_EXT_TOOL_BAR) >> /* Clear the matrix of the tool-bar window, if any. */ >> if (WINDOWP (f->tool_bar_window)) <<<<<<<<<<<<<<<<<< >> clear_glyph_matrix (XWINDOW = (f->tool_bar_window)->current_matrix); >> #endif >> >> Type RET at the end, then type '{' and RET. The '{' gets indented >> correctly, but there's no additional two-column indent after RET that >> follows '{'. > > This is due to how 'c-ts-common-statement-offset' works, which seems = to > assume balanced pairs. I think this is "unrelated" to this bug. > >> >> RET after preprocessor directives outside of functions indents by 2 >> columns. For example, here: >> >> #if 0 >> /* Swap glyphs between two glyph rows A and B. This exchanges glyph >> contents, i.e. glyph structure contents are exchanged between A = and >> B without changing glyph pointers in A and B. */ >> >> If you type RET after "#if 0", point goes to column 2, not zero. >> Interestingly, if you type RET at the end of the last line of the >> following comment, point goes to column zero, as expected. > > This one I'll fix. > >> >> Line 1357 of dispnew.c: >> >> static void >> free_glyph_pool (struct glyph_pool *pool) >> { >> if (pool) >> { >> #if defined GLYPH_DEBUG && defined ENABLE_CHECKING <<<<<<<<<<<<<<< >> /* More freed than allocated? */ >> --glyph_pool_count; >> eassert (glyph_pool_count >=3D 0); >> #endif >> xfree (pool->glyphs); >> xfree (pool); >> } >> } >> >> Type RET at the end of the indicated line: point goes to column 6, as >> expected. But if you then type "{ RET", point gets indented by 4 >> columns, not by 2. And even typing a semi-colon afterwards doesn't >> fix the indentation. >> >> Similarly here: >> >> static void >> adjust_frame_glyphs_for_window_redisplay (struct frame *f) >> { >> eassert (FRAME_WINDOW_P (f) && FRAME_LIVE_P (f)); >> >> /* Allocate/reallocate window matrices. */ >> allocate_matrices_for_window_redisplay (XWINDOW (FRAME_ROOT_WINDOW = (f))); >> >> #if defined (HAVE_X_WINDOWS) && ! defined (USE_X_TOOLKIT) && ! = defined (USE_GTK) >> /* Allocate/ reallocate matrices of the dummy window used to = display >> the menu bar under X when no X toolkit support is available. */ >> { <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> /* Allocate a dummy window if not already done. */ >> struct window *w; >> if (NILP (f->menu_bar_window)) >> >> The indicated line is 2166 in dispnew.c. If you type RET there, = point >> will be indented to column 6, not 4 as expected. And if you type RET >> at the end of the following comment line, not only will point be >> over-indented, but the comment itself will also be reindented >> incorrectly. >> >> Anyway, this works much better than the original code, and I saw no >> regressions, so I think you should install this. Perhaps consider >> adding comments explaining any tricky parts of handling this, so that >> future hackers will know what to do and what to avoid. Bonus points >> for adding tests for this, so that we don't easily regress in the >> future. >> > > Great! Will do :-) > >> Thanks! > > No problem! Sorry for joining late, I just added some change to support "indent according to previous sibling" requested by someone on emacs-devel, and noticed this change. IIUC, the goal is to indent whatever inside a preproc directive as if the directive doesn=E2=80=99t exist, right? If = that is true, we should be fine by just using c-ts-common-statement-offset. Am I missing something? Statements inside labels are indented similarly, and this is the rule used for them: ((parent-is "labeled_statement") point-min c-ts-common-statement-offset) I tried to rewrite the current rule for preproc in the similar fasion, ie, from ((n-p-gp nil "preproc" "translation_unit") point-min 0) ((n-p-gp nil "\n" "preproc") great-grand-parent = c-ts-mode--preproc-offset) ((parent-is "preproc") grand-parent c-ts-mode-indent-offset) to ((n-p-gp nil "\n" "preproc") point-min c-ts-common-statement-offset) ((parent-is "preproc") point-min c-ts-common-statement-offset) and the test can pass. Yuan From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Feb 2023 06:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Yuan Fu Cc: Eli Zaretskii , 61558@debbugs.gnu.org Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.16773070826231 (code B ref 61558); Sat, 25 Feb 2023 06:39:02 +0000 Received: (at 61558) by debbugs.gnu.org; 25 Feb 2023 06:38:02 +0000 Received: from localhost ([127.0.0.1]:38858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVoC1-0001cC-L6 for submit@debbugs.gnu.org; Sat, 25 Feb 2023 01:38:02 -0500 Received: from out-38.mta0.migadu.com ([91.218.175.38]:23429) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVoBz-0001c0-6Q for 61558@debbugs.gnu.org; Sat, 25 Feb 2023 01:38:00 -0500 Date: Sat, 25 Feb 2023 07:37:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1677307077; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QT46kevL69xQ+uBZpC1qD2DwvWoI8KpFlNYVYAuLBUA=; b=FUBM+WW8/exydf7g6GPuHESxVgR6I9V1UmvyiZHBW4nO2G+78E7e1cEkLRDyTtV16GK2iX i6YXicFkXmIpWzOqwwcb1EsmR3wIS96+psDEzKu+P/DwafJWGT99Wc1EYNP+PHlYdUuDut ks6m/ixKdjIfbEyuhZf4UOVURrosn5nZTm5atRt+5lJylvo5YJE0y6z2wC9o2fUnZrIfMf VmVdpmUjipZPSWjRZ/FCw+2gsX68p6sAm7WjnTcMx9fQ5yiTAsBIOOJfwhjjP27FIwkMUm HWb/a2CknZTano++d9vfVkkYyPg3q04PvyxpfMJlH5/ZxY61FlkqdpV2Hk4vgg== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill In-Reply-To: References: Message-ID: <5EE12293-A537-4D8B-A17B-A5BCAC36D14A@thornhill.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Spam-Score: 0.0 (/) 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 25 February 2023 05:30:02 CET, Yuan Fu wrote: > >Theodor Thornhill writes: > >> Eli Zaretskii writes: >> >>>> From: Theodor Thornhill >>>> Cc: 61558@debbugs=2Egnu=2Eorg >>>> Date: Sat, 18 Feb 2023 22:30:06 +0100 >>>>=20 >>>> >> Typing RET at the end of the two marked lines goes to column zero >>>> >> instead of the expected non-zero column=2E So it sounds like #def= ine >>>> >> and #undef are also not handled correctly yet=2E >>>> > >>>> > Yeah, luckily it indents correctly after you start to type=2E I'll= try to >>>> > see if I can make some specific handling for this=2E >>>> > >>>> > Theo >>>> > >>>>=20 >>>> Scratch that=2E Can you test this for me? I think I got it=2E >>> >>> Thanks, this seems to work better=2E Some problems still remain, >>> though=2E >>> >>> Line 807 of dispnew=2Ec: >>> >>> #if defined (HAVE_WINDOW_SYSTEM) && ! defined (HAVE_EXT_TOOL_BAR) >>> /* Clear the matrix of the tool-bar window, if any=2E */ >>> if (WINDOWP (f->tool_bar_window)) <<<<<<<<<<<<<<<<<< >>> clear_glyph_matrix (XWINDOW (f->tool_bar_window)->current_matrix); >>> #endif >>> >>> Type RET at the end, then type '{' and RET=2E The '{' gets indented >>> correctly, but there's no additional two-column indent after RET that >>> follows '{'=2E >> >> This is due to how 'c-ts-common-statement-offset' works, which seems to >> assume balanced pairs=2E I think this is "unrelated" to this bug=2E >> >>> >>> RET after preprocessor directives outside of functions indents by 2 >>> columns=2E For example, here: >>> >>> #if 0 >>> /* Swap glyphs between two glyph rows A and B=2E This exchanges glyph >>> contents, i=2Ee=2E glyph structure contents are exchanged between A= and >>> B without changing glyph pointers in A and B=2E */ >>> >>> If you type RET after "#if 0", point goes to column 2, not zero=2E >>> Interestingly, if you type RET at the end of the last line of the >>> following comment, point goes to column zero, as expected=2E >> >> This one I'll fix=2E >> >>> >>> Line 1357 of dispnew=2Ec: >>> >>> static void >>> free_glyph_pool (struct glyph_pool *pool) >>> { >>> if (pool) >>> { >>> #if defined GLYPH_DEBUG && defined ENABLE_CHECKING <<<<<<<<<<<<<<< >>> /* More freed than allocated? */ >>> --glyph_pool_count; >>> eassert (glyph_pool_count >=3D 0); >>> #endif >>> xfree (pool->glyphs); >>> xfree (pool); >>> } >>> } >>> >>> Type RET at the end of the indicated line: point goes to column 6, as >>> expected=2E But if you then type "{ RET", point gets indented by 4 >>> columns, not by 2=2E And even typing a semi-colon afterwards doesn't >>> fix the indentation=2E >>> >>> Similarly here: >>> >>> static void >>> adjust_frame_glyphs_for_window_redisplay (struct frame *f) >>> { >>> eassert (FRAME_WINDOW_P (f) && FRAME_LIVE_P (f)); >>> >>> /* Allocate/reallocate window matrices=2E */ >>> allocate_matrices_for_window_redisplay (XWINDOW (FRAME_ROOT_WINDOW (= f))); >>> >>> #if defined (HAVE_X_WINDOWS) && ! defined (USE_X_TOOLKIT) && ! defined= (USE_GTK) >>> /* Allocate/ reallocate matrices of the dummy window used to display >>> the menu bar under X when no X toolkit support is available=2E *= / >>> { <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >>> /* Allocate a dummy window if not already done=2E */ >>> struct window *w; >>> if (NILP (f->menu_bar_window)) >>> >>> The indicated line is 2166 in dispnew=2Ec=2E If you type RET there, p= oint >>> will be indented to column 6, not 4 as expected=2E And if you type RE= T >>> at the end of the following comment line, not only will point be >>> over-indented, but the comment itself will also be reindented >>> incorrectly=2E >>> >>> Anyway, this works much better than the original code, and I saw no >>> regressions, so I think you should install this=2E Perhaps consider >>> adding comments explaining any tricky parts of handling this, so that >>> future hackers will know what to do and what to avoid=2E Bonus points >>> for adding tests for this, so that we don't easily regress in the >>> future=2E >>> >> >> Great! Will do :-) >> >>> Thanks! >> >> No problem! > > >Sorry for joining late, I just added some change to support "indent >according to previous sibling" requested by someone on emacs-devel, and >noticed this change=2E IIUC, the goal is to indent whatever inside a >preproc directive as if the directive doesn=E2=80=99t exist, right? If th= at is >true, we should be fine by just using c-ts-common-statement-offset=2E Am = I >missing something? > >Statements inside labels are indented similarly, and this is the rule >used for them: > >((parent-is "labeled_statement") point-min c-ts-common-statement-offset) > >I tried to rewrite the current rule for preproc in the similar fasion, >ie, from > >((n-p-gp nil "preproc" "translation_unit") point-min 0) >((n-p-gp nil "\n" "preproc") great-grand-parent c-ts-mode--preproc-offset= ) >((parent-is "preproc") grand-parent c-ts-mode-indent-offset) > >to > >((n-p-gp nil "\n" "preproc") point-min c-ts-common-statement-offset) >((parent-is "preproc") point-min c-ts-common-statement-offset) > >and the test can pass=2E > >Yuan I have no strong opinions on this, but imo that function is pretty heavy a= t this point, and the rules i supplied are simple enough=2E C-ts-common-str= tement-offset is an engine of its own and pretty complex by now, don't you = think? From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Feb 2023 08:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Theodor Thornhill Cc: Eli Zaretskii , 61558@debbugs.gnu.org Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.167740139422629 (code B ref 61558); Sun, 26 Feb 2023 08:50:02 +0000 Received: (at 61558) by debbugs.gnu.org; 26 Feb 2023 08:49:54 +0000 Received: from localhost ([127.0.0.1]:42320 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWCjB-0005su-Nh for submit@debbugs.gnu.org; Sun, 26 Feb 2023 03:49:54 -0500 Received: from mail-pl1-f182.google.com ([209.85.214.182]:33766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWCj8-0005si-U2 for 61558@debbugs.gnu.org; Sun, 26 Feb 2023 03:49:51 -0500 Received: by mail-pl1-f182.google.com with SMTP id p6so2941701plf.0 for <61558@debbugs.gnu.org>; Sun, 26 Feb 2023 00:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GxhZq0m2sgsTcndXJsdqMtDTIhpYf+iq/P/aYJDS6Nk=; b=lwhRVeOS4nhZY3Qad3gTTNsqIU9kqYoOGmNwZ7K+9bCQ8dMJ3/Hd888KerZNUZdooc va/4rRpC0B140VcUYKIzBJJgqcOLl+jjojfnCdLmIztNXDoUZT0DivQOi/KieLLOETcr fF3X4V3rqtKnTDIsKbQ4IsCvSC0gMm6RhUXdIRhQYj4ruxXFsIvk4Z3VMv9+Kak+RhOA Su+5r/Fpyj/Mgu0Kp6LPqpU274VC45bM5n+6S+K/1b3NthmiK7O+ebjq72/e4Y9gfmIa VHl0QCZVdoBZVw5IWMvBualT4K77HN4FnAeLBJg9l17DT1Hc1Rj7XKqFBFxIcsRcBNMI YduA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GxhZq0m2sgsTcndXJsdqMtDTIhpYf+iq/P/aYJDS6Nk=; b=KclueGxBuxayaKbK6N3KTtRAacL+WbWs/nrIwSP/3IdgBsqZ8VqqGfYHiSH9XUGeDa mN8Fcp2ceDWUHfYkjrm2y70dSxbuZVJb0u8NnYDLZTeKOu6NXHLQWn3PXxZli+IvOyfO sdkRwj+KUUMxnjfUu/Py119J8pSSy6p0DyV8x37oFmgaEPHR1GMgF5Z0cwbsn9Qqce6w 2rcDV2oBLcZcvi3yXASkEsdwHr2hSJ1IfiR+DqpzeL1XgE/5ypJqeVf/zmcAZhCSCfrO UMndwOhxHFxb/7EZJYcVRk43rk2v5lnKftVRgsQuCPI79BF6nrY8hVITnLyLX7+81gnX gHBw== X-Gm-Message-State: AO0yUKXQz0NYYdw6Ji8QkV1W7VuR6yaZbkYq6Jja9JbAgh6qWemQ/e+2 nVl9k1VzKJY8RiCZdXJp0Yo= X-Google-Smtp-Source: AK7set/yJiKqPG7G3TLAqi89/PO74YT/FsyJzlEjUEm2krTtNDzwQ++Kd2MTbaPxIiy+HJWB1nw6Vw== X-Received: by 2002:a17:902:7408:b0:19c:ff35:35d1 with SMTP id g8-20020a170902740800b0019cff3535d1mr2439478pll.6.1677401385116; Sun, 26 Feb 2023 00:49:45 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id z6-20020a170903018600b0019a777ff433sm2342997plg.17.2023.02.26.00.49.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Feb 2023 00:49:44 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) From: Yuan Fu In-Reply-To: <5EE12293-A537-4D8B-A17B-A5BCAC36D14A@thornhill.no> Date: Sun, 26 Feb 2023 00:49:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5EE12293-A537-4D8B-A17B-A5BCAC36D14A@thornhill.no> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spam-Score: 0.0 (/) 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 Feb 24, 2023, at 10:37 PM, Theodor Thornhill = wrote: >=20 >=20 >=20 > On 25 February 2023 05:30:02 CET, Yuan Fu wrote: >>=20 >> Theodor Thornhill writes: >>=20 >>> Eli Zaretskii writes: >>>=20 >>>>> From: Theodor Thornhill >>>>> Cc: 61558@debbugs.gnu.org >>>>> Date: Sat, 18 Feb 2023 22:30:06 +0100 >>>>>=20 >>>>>>> Typing RET at the end of the two marked lines goes to column = zero >>>>>>> instead of the expected non-zero column. So it sounds like = #define >>>>>>> and #undef are also not handled correctly yet. >>>>>>=20 >>>>>> Yeah, luckily it indents correctly after you start to type. I'll = try to >>>>>> see if I can make some specific handling for this. >>>>>>=20 >>>>>> Theo >>>>>>=20 >>>>>=20 >>>>> Scratch that. Can you test this for me? I think I got it. >>>>=20 >>>> Thanks, this seems to work better. Some problems still remain, >>>> though. >>>>=20 >>>> Line 807 of dispnew.c: >>>>=20 >>>> #if defined (HAVE_WINDOW_SYSTEM) && ! defined (HAVE_EXT_TOOL_BAR) >>>> /* Clear the matrix of the tool-bar window, if any. */ >>>> if (WINDOWP (f->tool_bar_window)) <<<<<<<<<<<<<<<<<< >>>> clear_glyph_matrix (XWINDOW = (f->tool_bar_window)->current_matrix); >>>> #endif >>>>=20 >>>> Type RET at the end, then type '{' and RET. The '{' gets indented >>>> correctly, but there's no additional two-column indent after RET = that >>>> follows '{'. >>>=20 >>> This is due to how 'c-ts-common-statement-offset' works, which seems = to >>> assume balanced pairs. I think this is "unrelated" to this bug. >>>=20 >>>>=20 >>>> RET after preprocessor directives outside of functions indents by 2 >>>> columns. For example, here: >>>>=20 >>>> #if 0 >>>> /* Swap glyphs between two glyph rows A and B. This exchanges = glyph >>>> contents, i.e. glyph structure contents are exchanged between A = and >>>> B without changing glyph pointers in A and B. */ >>>>=20 >>>> If you type RET after "#if 0", point goes to column 2, not zero. >>>> Interestingly, if you type RET at the end of the last line of the >>>> following comment, point goes to column zero, as expected. >>>=20 >>> This one I'll fix. >>>=20 >>>>=20 >>>> Line 1357 of dispnew.c: >>>>=20 >>>> static void >>>> free_glyph_pool (struct glyph_pool *pool) >>>> { >>>> if (pool) >>>> { >>>> #if defined GLYPH_DEBUG && defined ENABLE_CHECKING <<<<<<<<<<<<<<< >>>> /* More freed than allocated? */ >>>> --glyph_pool_count; >>>> eassert (glyph_pool_count >=3D 0); >>>> #endif >>>> xfree (pool->glyphs); >>>> xfree (pool); >>>> } >>>> } >>>>=20 >>>> Type RET at the end of the indicated line: point goes to column 6, = as >>>> expected. But if you then type "{ RET", point gets indented by 4 >>>> columns, not by 2. And even typing a semi-colon afterwards doesn't >>>> fix the indentation. >>>>=20 >>>> Similarly here: >>>>=20 >>>> static void >>>> adjust_frame_glyphs_for_window_redisplay (struct frame *f) >>>> { >>>> eassert (FRAME_WINDOW_P (f) && FRAME_LIVE_P (f)); >>>>=20 >>>> /* Allocate/reallocate window matrices. */ >>>> allocate_matrices_for_window_redisplay (XWINDOW (FRAME_ROOT_WINDOW = (f))); >>>>=20 >>>> #if defined (HAVE_X_WINDOWS) && ! defined (USE_X_TOOLKIT) && ! = defined (USE_GTK) >>>> /* Allocate/ reallocate matrices of the dummy window used to = display >>>> the menu bar under X when no X toolkit support is available. = */ >>>> { <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >>>> /* Allocate a dummy window if not already done. */ >>>> struct window *w; >>>> if (NILP (f->menu_bar_window)) >>>>=20 >>>> The indicated line is 2166 in dispnew.c. If you type RET there, = point >>>> will be indented to column 6, not 4 as expected. And if you type = RET >>>> at the end of the following comment line, not only will point be >>>> over-indented, but the comment itself will also be reindented >>>> incorrectly. >>>>=20 >>>> Anyway, this works much better than the original code, and I saw no >>>> regressions, so I think you should install this. Perhaps consider >>>> adding comments explaining any tricky parts of handling this, so = that >>>> future hackers will know what to do and what to avoid. Bonus = points >>>> for adding tests for this, so that we don't easily regress in the >>>> future. >>>>=20 >>>=20 >>> Great! Will do :-) >>>=20 >>>> Thanks! >>>=20 >>> No problem! >>=20 >>=20 >> Sorry for joining late, I just added some change to support "indent >> according to previous sibling" requested by someone on emacs-devel, = and >> noticed this change. IIUC, the goal is to indent whatever inside a >> preproc directive as if the directive doesn=E2=80=99t exist, right? = If that is >> true, we should be fine by just using c-ts-common-statement-offset. = Am I >> missing something? >>=20 >> Statements inside labels are indented similarly, and this is the rule >> used for them: >>=20 >> ((parent-is "labeled_statement") point-min = c-ts-common-statement-offset) >>=20 >> I tried to rewrite the current rule for preproc in the similar = fasion, >> ie, from >>=20 >> ((n-p-gp nil "preproc" "translation_unit") point-min 0) >> ((n-p-gp nil "\n" "preproc") great-grand-parent = c-ts-mode--preproc-offset) >> ((parent-is "preproc") grand-parent c-ts-mode-indent-offset) >>=20 >> to >>=20 >> ((n-p-gp nil "\n" "preproc") point-min c-ts-common-statement-offset) >> ((parent-is "preproc") point-min c-ts-common-statement-offset) >>=20 >> and the test can pass. >>=20 >> Yuan >=20 >=20 > I have no strong opinions on this, but imo that function is pretty = heavy at this point, and the rules i supplied are simple enough. = C-ts-common-strtement-offset is an engine of its own and pretty complex = by now, don't you think? >=20 Sure. As long you are satisfied, I=E2=80=99m fine with it. = c-ts-common-statement-offset is indeed too heavy. I=E2=80=99m working to = improve c-ts-common-statement-offset and make it more like parent-bol = (so it=E2=80=99s lighter). Yuan From unknown Fri Jun 20 20:01:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Feb 2023 10:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61558 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Yuan Fu Cc: Eli Zaretskii , 61558@debbugs.gnu.org Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.1677407456934 (code B ref 61558); Sun, 26 Feb 2023 10:31:02 +0000 Received: (at 61558) by debbugs.gnu.org; 26 Feb 2023 10:30:56 +0000 Received: from localhost ([127.0.0.1]:42383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWEIx-0000Ez-MZ for submit@debbugs.gnu.org; Sun, 26 Feb 2023 05:30:56 -0500 Received: from out-10.mta1.migadu.com ([95.215.58.10]:15566) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWEIv-0000Ep-6X for 61558@debbugs.gnu.org; Sun, 26 Feb 2023 05:30:54 -0500 Date: Sun, 26 Feb 2023 11:30:44 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1677407451; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZN3JPgWEpXsqCISXBPGuAr7k1pLttbE9cs5ZnNPlhzY=; b=daV2KO92+AedmT+LJc2vOitGto0Pxh+hqMmNKUvacJnltYBEj+/XfzDDHCjRencvXFSLVg c6VVqtsxE77je3O9tRBCszR8Qf0eyptI7rJCxAhF1K+54g/zypvbxZC2exn+9QFwflsGLU Z1AAXwylGtF2rAfisRHCQCQt13LDnkPPNLzVVJFcnaTkFcBsKxEsJe90BqGfQ6wjlK6Ord zw09xQbUROiSllNj/NMqinW95hG81BS3bMC3qh4WckaA5VSO9FbNIP9jUNJaDMUfR35ONA N14fDJ4L2Hjh+HFHHLE80uUSqBx0QZmZ5kBzlxyuigNKolCzCVOwer9n7hxE0Q== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Theodor Thornhill In-Reply-To: References: <5EE12293-A537-4D8B-A17B-A5BCAC36D14A@thornhill.no> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT X-Spam-Score: 0.0 (/) 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 26 February 2023 09:49:33 CET, Yuan Fu wrote: > > >> On Feb 24, 2023, at 10:37 PM, Theodor Thornhill w= rote: >>=20 >>=20 >>=20 >> On 25 February 2023 05:30:02 CET, Yuan Fu wrote: >>>=20 >>> Theodor Thornhill writes: >>>=20 >>>> Eli Zaretskii writes: >>>>=20 >>>>>> From: Theodor Thornhill >>>>>> Cc: 61558@debbugs=2Egnu=2Eorg >>>>>> Date: Sat, 18 Feb 2023 22:30:06 +0100 >>>>>>=20 >>>>>>>> Typing RET at the end of the two marked lines goes to column zero >>>>>>>> instead of the expected non-zero column=2E So it sounds like #de= fine >>>>>>>> and #undef are also not handled correctly yet=2E >>>>>>>=20 >>>>>>> Yeah, luckily it indents correctly after you start to type=2E I'l= l try to >>>>>>> see if I can make some specific handling for this=2E >>>>>>>=20 >>>>>>> Theo >>>>>>>=20 >>>>>>=20 >>>>>> Scratch that=2E Can you test this for me? I think I got it=2E >>>>>=20 >>>>> Thanks, this seems to work better=2E Some problems still remain, >>>>> though=2E >>>>>=20 >>>>> Line 807 of dispnew=2Ec: >>>>>=20 >>>>> #if defined (HAVE_WINDOW_SYSTEM) && ! defined (HAVE_EXT_TOOL_BAR) >>>>> /* Clear the matrix of the tool-bar window, if any=2E */ >>>>> if (WINDOWP (f->tool_bar_window)) <<<<<<<<<<<<<<<<<< >>>>> clear_glyph_matrix (XWINDOW (f->tool_bar_window)->current_matrix)= ; >>>>> #endif >>>>>=20 >>>>> Type RET at the end, then type '{' and RET=2E The '{' gets indented >>>>> correctly, but there's no additional two-column indent after RET tha= t >>>>> follows '{'=2E >>>>=20 >>>> This is due to how 'c-ts-common-statement-offset' works, which seems = to >>>> assume balanced pairs=2E I think this is "unrelated" to this bug=2E >>>>=20 >>>>>=20 >>>>> RET after preprocessor directives outside of functions indents by 2 >>>>> columns=2E For example, here: >>>>>=20 >>>>> #if 0 >>>>> /* Swap glyphs between two glyph rows A and B=2E This exchanges gly= ph >>>>> contents, i=2Ee=2E glyph structure contents are exchanged between = A and >>>>> B without changing glyph pointers in A and B=2E */ >>>>>=20 >>>>> If you type RET after "#if 0", point goes to column 2, not zero=2E >>>>> Interestingly, if you type RET at the end of the last line of the >>>>> following comment, point goes to column zero, as expected=2E >>>>=20 >>>> This one I'll fix=2E >>>>=20 >>>>>=20 >>>>> Line 1357 of dispnew=2Ec: >>>>>=20 >>>>> static void >>>>> free_glyph_pool (struct glyph_pool *pool) >>>>> { >>>>> if (pool) >>>>> { >>>>> #if defined GLYPH_DEBUG && defined ENABLE_CHECKING <<<<<<<<<<<<<<< >>>>> /* More freed than allocated? */ >>>>> --glyph_pool_count; >>>>> eassert (glyph_pool_count >=3D 0); >>>>> #endif >>>>> xfree (pool->glyphs); >>>>> xfree (pool); >>>>> } >>>>> } >>>>>=20 >>>>> Type RET at the end of the indicated line: point goes to column 6, a= s >>>>> expected=2E But if you then type "{ RET", point gets indented by 4 >>>>> columns, not by 2=2E And even typing a semi-colon afterwards doesn'= t >>>>> fix the indentation=2E >>>>>=20 >>>>> Similarly here: >>>>>=20 >>>>> static void >>>>> adjust_frame_glyphs_for_window_redisplay (struct frame *f) >>>>> { >>>>> eassert (FRAME_WINDOW_P (f) && FRAME_LIVE_P (f)); >>>>>=20 >>>>> /* Allocate/reallocate window matrices=2E */ >>>>> allocate_matrices_for_window_redisplay (XWINDOW (FRAME_ROOT_WINDOW = (f))); >>>>>=20 >>>>> #if defined (HAVE_X_WINDOWS) && ! defined (USE_X_TOOLKIT) && ! defin= ed (USE_GTK) >>>>> /* Allocate/ reallocate matrices of the dummy window used to displa= y >>>>> the menu bar under X when no X toolkit support is available=2E = */ >>>>> { <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >>>>> /* Allocate a dummy window if not already done=2E */ >>>>> struct window *w; >>>>> if (NILP (f->menu_bar_window)) >>>>>=20 >>>>> The indicated line is 2166 in dispnew=2Ec=2E If you type RET there,= point >>>>> will be indented to column 6, not 4 as expected=2E And if you type = RET >>>>> at the end of the following comment line, not only will point be >>>>> over-indented, but the comment itself will also be reindented >>>>> incorrectly=2E >>>>>=20 >>>>> Anyway, this works much better than the original code, and I saw no >>>>> regressions, so I think you should install this=2E Perhaps consider >>>>> adding comments explaining any tricky parts of handling this, so tha= t >>>>> future hackers will know what to do and what to avoid=2E Bonus poin= ts >>>>> for adding tests for this, so that we don't easily regress in the >>>>> future=2E >>>>>=20 >>>>=20 >>>> Great! Will do :-) >>>>=20 >>>>> Thanks! >>>>=20 >>>> No problem! >>>=20 >>>=20 >>> Sorry for joining late, I just added some change to support "indent >>> according to previous sibling" requested by someone on emacs-devel, an= d >>> noticed this change=2E IIUC, the goal is to indent whatever inside a >>> preproc directive as if the directive doesn=E2=80=99t exist, right? If= that is >>> true, we should be fine by just using c-ts-common-statement-offset=2E = Am I >>> missing something? >>>=20 >>> Statements inside labels are indented similarly, and this is the rule >>> used for them: >>>=20 >>> ((parent-is "labeled_statement") point-min c-ts-common-statement-offse= t) >>>=20 >>> I tried to rewrite the current rule for preproc in the similar fasion, >>> ie, from >>>=20 >>> ((n-p-gp nil "preproc" "translation_unit") point-min 0) >>> ((n-p-gp nil "\n" "preproc") great-grand-parent c-ts-mode--preproc-off= set) >>> ((parent-is "preproc") grand-parent c-ts-mode-indent-offset) >>>=20 >>> to >>>=20 >>> ((n-p-gp nil "\n" "preproc") point-min c-ts-common-statement-offset) >>> ((parent-is "preproc") point-min c-ts-common-statement-offset) >>>=20 >>> and the test can pass=2E >>>=20 >>> Yuan >>=20 >>=20 >> I have no strong opinions on this, but imo that function is pretty heav= y at this point, and the rules i supplied are simple enough=2E C-ts-common-= strtement-offset is an engine of its own and pretty complex by now, don't y= ou think? >>=20 > >Sure=2E As long you are satisfied, I=E2=80=99m fine with it=2E c-ts-commo= n-statement-offset is indeed too heavy=2E I=E2=80=99m working to improve c-= ts-common-statement-offset and make it more like parent-bol (so it=E2=80=99= s lighter)=2E > >Yuan > Nice! I think we can revisit it if we need to=2E I think it works pretty well ri= ght now :) Theo