From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#63957: 29.0.91; c-ts-mode: incorrect fontification in alloc.c Date: Mon, 12 Jun 2023 02:16:51 -0700 Message-ID: <14362329-D74B-42C9-879D-CE61CA6969A6@gmail.com> References: <83mt1a33a4.fsf@gnu.org> <83legu333f.fsf@gnu.org> <83zg57zqhf.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) 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="9074"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63957@debbugs.gnu.org, Theodor Thornhill To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 12 11:18:21 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 1q8dgr-00023x-3B for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 12 Jun 2023 11:18:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q8dgd-0007v0-0K; Mon, 12 Jun 2023 05:18:07 -0400 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 1q8dgY-0007rF-QU for bug-gnu-emacs@gnu.org; Mon, 12 Jun 2023 05:18:05 -0400 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 1q8dgY-0004ih-I1 for bug-gnu-emacs@gnu.org; Mon, 12 Jun 2023 05:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q8dgY-0001qt-DD for bug-gnu-emacs@gnu.org; Mon, 12 Jun 2023 05:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Jun 2023 09:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63957 X-GNU-PR-Package: emacs Original-Received: via spool by 63957-submit@debbugs.gnu.org id=B63957.16865614347030 (code B ref 63957); Mon, 12 Jun 2023 09:18:02 +0000 Original-Received: (at 63957) by debbugs.gnu.org; 12 Jun 2023 09:17:14 +0000 Original-Received: from localhost ([127.0.0.1]:38835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8dfl-0001pK-MU for submit@debbugs.gnu.org; Mon, 12 Jun 2023 05:17:13 -0400 Original-Received: from mail-pl1-f173.google.com ([209.85.214.173]:60429) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8dfj-0001p5-L1 for 63957@debbugs.gnu.org; Mon, 12 Jun 2023 05:17:12 -0400 Original-Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-1b3c5389fa2so5839255ad.0 for <63957@debbugs.gnu.org>; Mon, 12 Jun 2023 02:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686561425; x=1689153425; 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=s9zR1vMF7GIHCKkVjddFtt07Mn+fId4SgUhWF/RNktA=; b=YhOqafII/bIk29yB7d/0BnXSzoPnV7VY7/jg1t4JADTdQvHeDSJheqe6JgM/fkuVqw ndtEMprALCl98Na33zuuh78T5RcVRY8IkcISOXE0MmATNZQ8bTodF/A7g96tUDqNy4kb ggtBAMlxp14J5Ef4Rykdej1q3F1tWIWvUfGEmUsGLaO/FOGyB8wfe10jYans8GaUWtDe s6Kt7m/brs7vM2zRLrw1l/CzfItuK540c1MgxCyG+ps3nyKKBZPMupQMmEFXk63+kVeS 1rM2xhmlbvfJ0lGNfogsyEcVJhH87U0GpSqQBRdys2347HCAsV9WOQqFXBCvDMEErFNR KNLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686561425; x=1689153425; 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=s9zR1vMF7GIHCKkVjddFtt07Mn+fId4SgUhWF/RNktA=; b=TVu8pNIbIX4NbjrkqvE95RHV9Ey0/0OERn23GCqZOAF4mHHN1/gFRd83z6Rqj4z0WI DUs/PS7EuGWURM78xliBjGZM2lzTPuYdoMl9YTWiYyhv9goKB+jYpgiQkPaPB6ah+EVt v6nXfEoVuOYa3/RtiOO5/UbwwQcyctG4yNfvLYpAW/tdW8Qtciri3hGDGN4whHGMND1z BouBI8L2JfcDtEVvPfGJDLyndIi5ruDxhUqbYHivH6e7OkofUj3pPF83Dt2Xocdhm55+ DjH6ewW2tI46TWYWQhSFJl4y25VCDz/TDw/3WTyxUcgrMRwdO3jJBzChTfgb2UHM5uDK dqPw== X-Gm-Message-State: AC+VfDwkxYfpD9rpCcdSmOvdNNvGH73no0EKk9MiGY65uVPMBCybcbmW RN8ETEDg0LxASWLDZ+eMcwD6LKPhUOI= X-Google-Smtp-Source: ACHHUZ4tT3BcbLmg4S+4tSXMb9MdQLXq105oiAP2B14DkqfRlDuahLRmV1bSPioKOuIzDwTiQyuGeg== X-Received: by 2002:a17:903:2582:b0:1b2:43a2:f2d with SMTP id jb2-20020a170903258200b001b243a20f2dmr5022870plb.32.1686561425510; Mon, 12 Jun 2023 02:17:05 -0700 (PDT) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id f13-20020a170902ce8d00b001b0358848b0sm1030078plg.161.2023.06.12.02.17.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2023 02:17:04 -0700 (PDT) In-Reply-To: <83zg57zqhf.fsf@gnu.org> X-Mailer: Apple Mail (2.3731.600.7) 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:263262 Archived-At: >>=20 >>>>> emacs -Q >>>>> C-x C-f src/alloc.c RET >>>>> M-x c-ts-mode RET >>>>> C-u 3184 M-g g >>>>>=20 >>>>> Observe that several "else if" clauses in the following fragment = are not >>>>> fontified correctly: >>>>=20 >>>> Adding the relevant folks. >>>>=20 >>>> Could you guys please look into this issue? >>=20 >> Ok, so this is one of such cases where the preproc directives severs = the code and the parser can=E2=80=99t recover very well. We can cover it = over by just fontifying =E2=80=9Celse if=E2=80=9D with keyword face, but = there are a million ways for the preproc directive to mess up the = parser, I don=E2=80=99t think we can cover every case. >=20 > Can you explain what is special in this particular case that is > different from other preprocessor directives? I'd like to think if > this case is important enough to try harder. I wouldn=E2=80=99t say that this case is special, actually the cases we = were able to more or less fix are special. The problem with preproc = directives is that they can appear anywhere and break whatever construct = they appear in. (Because tree-sitter-c parses preproc constructs as = top-level constructs, higher than anything else.) Say there=E2=80=99s a struct: struct A { int a; int b; } If we add preproc directives: struct A { #if A int a; #else =20 int b; } #endif Now the parser will parse the "struct A {=E2=80=9C individually; parse = =E2=80=9Cint a;=E2=80=9D individually; and parse =E2=80=9Cint b; }=E2=80=9D= individually. So in general, if a preproc directives butchers some construct, the = first part is usually fine (eg, the =E2=80=9Cstruct A {=E2=80=9C part), = but the rest often have problems. Like a dangling =E2=80=9Celse if {}=E2=80= =9D in if-else-if, or a dangling =E2=80=9Cxxx }=E2=80=9D in a function = definition, or maybe a =E2=80=9Cdefault: xxx }=E2=80=9D in a = switch-case. The Emacs-specific macros we were able to =E2=80=9Cfix=E2=80=9D all have = a specific pattern, so we can find them and expect them to have a = certain shape, but the breakage caused by preproc directives don=E2=80=99t= really have a pattern. I can=E2=80=99t think of a good way to handle = them. I=E2=80=99m not against fixing these case-by-case, if the cases becomes = too many and not scalable, we can give up. Yuan=