From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#61558: 29.0.60; Indentation with c-ts-mode doesn't work in code guarded by #ifdef..#endif Date: Sat, 25 Feb 2023 07:37:55 +0100 Message-ID: <5EE12293-A537-4D8B-A17B-A5BCAC36D14A@thornhill.no> References: Reply-To: Theodor Thornhill Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34945"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 61558@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 25 07:39:39 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pVoDa-0008rx-Iy for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Feb 2023 07:39:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVoDR-0002or-Bn; Sat, 25 Feb 2023 01:39:29 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVoD1-0002Yb-84 for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2023 01:39:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVoD0-0002zT-P7 for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2023 01:39:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pVoD0-0001eD-CV for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2023 01:39:02 -0500 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 61558-submit@debbugs.gnu.org id=B61558.16773070826231 (code B ref 61558); Sat, 25 Feb 2023 06:39:02 +0000 Original-Received: (at 61558) by debbugs.gnu.org; 25 Feb 2023 06:38:02 +0000 Original-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 Original-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 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. In-Reply-To: X-Migadu-Flow: FLOW_OUT X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:256687 Archived-At: 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?