From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62951: 29.0.90; c-ts-mode: Incorrect fontification due to FOR_EACH_TAIL_SAFE Date: Sun, 23 Apr 2023 09:25:08 +0300 Message-ID: <83sfcryv23.fsf@gnu.org> References: <82E7ADEC-25BC-475B-8EE0-839FE78FF2F4@gmail.com> <83fs8s2xnk.fsf@gnu.org> <2BDA88D0-A870-4FE3-BAF8-350FBAA943BF@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="761"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62951@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 23 08:25:29 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 1pqTA8-000AXO-EV for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 23 Apr 2023 08:25:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pqT9l-0001vA-QU; Sun, 23 Apr 2023 02:25:05 -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 1pqT9j-0001uw-Bl for bug-gnu-emacs@gnu.org; Sun, 23 Apr 2023 02:25:03 -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 1pqT9j-0006U3-2V for bug-gnu-emacs@gnu.org; Sun, 23 Apr 2023 02:25:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pqT9i-0001wz-GM for bug-gnu-emacs@gnu.org; Sun, 23 Apr 2023 02:25:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 23 Apr 2023 06:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62951 X-GNU-PR-Package: emacs Original-Received: via spool by 62951-submit@debbugs.gnu.org id=B62951.16822310997483 (code B ref 62951); Sun, 23 Apr 2023 06:25:02 +0000 Original-Received: (at 62951) by debbugs.gnu.org; 23 Apr 2023 06:24:59 +0000 Original-Received: from localhost ([127.0.0.1]:44524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pqT9e-0001wd-VL for submit@debbugs.gnu.org; Sun, 23 Apr 2023 02:24:59 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47538) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pqT9a-0001wO-6w for 62951@debbugs.gnu.org; Sun, 23 Apr 2023 02:24:57 -0400 Original-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 1pqT9U-0006T1-Pw; Sun, 23 Apr 2023 02:24:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=vpapQpUKxDwDQ7h+po/hBWPPbiPh2SlLGRgrvJ4m1oE=; b=EY341BTjHEbo/5ywIatF P+mwQ6MjDjsl85+Brvp2rgFBZckat2dG3BU0dvpIEadeb70vl39BEqrck87VB6+bvKhre1Wp95o2B hu5u68r7p7++mgX52L9ylzx0zZmVASqrM+umUKjxgjNk4s7C8vP+pABq+zLJhmNx0f+VFiqWcDodb 8lY+Si13MoDTmPwUkyI0fNv4xM3oZj16/+Qj8hoKXyDLd7IIqoVsyiFoJwzXinNCbPYZt7lFIuuGD IpmoGgYr6dKomWE6IDpw69MnxGDZtg4ZSWUvU0mo7XycR7CbiFRZopxhvuq98got4nHikEuW1SgN0 Qyc+y6Fvg/T3UQ==; Original-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 1pqT9U-0002g0-4X; Sun, 23 Apr 2023 02:24:48 -0400 In-Reply-To: <2BDA88D0-A870-4FE3-BAF8-350FBAA943BF@gmail.com> (message from Yuan Fu on Sat, 22 Apr 2023 17:28:25 -0700) 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:260496 Archived-At: > From: Yuan Fu > Date: Sat, 22 Apr 2023 17:28:25 -0700 > Cc: 62951@debbugs.gnu.org > > >> I’m aware of this issue, but the truth is there isn’t a good solution to > >> it. We need to recognize FOR_EACH_TAIL_SAFE (not hard) and fix arbitrary > >> code after it (hard). In this case it’s a if statement, with macro calls > >> and AND operation in it’s condition, it’s already three things we need > >> to recognize and somehow handle. It can also be a for loop, a switch > >> case, a function call, a while loop. If we want to fix FOR_EACH_TAIL we > >> would need to handle every possible thing, at that point we might as > >> well have wrote a parser :-) > > > > Sorry, I don't understand the difficulties. The body of FOR_EACH_TAIL > > and a few similar macros we use could be on of the following: > > > > . a single simple statement > > . an 'if' clause > > . a 'while' loop > > . a 'do' loop > > . a 'for' loop > > . a brace-delimited block (this one already works, AFAICS, so we > > perhaps need not anything about it) > > > > (In practice, only the first 2 and the last one are used, AFAICS.) > > > > Doesn't tree-sitter tell us enough to figure out which of the above is > > in the body? If so, why would we need to write a full parser? > > Ok, the full parser part is a bit exaggeration :-) But my point is it’s a lot of dirty code for a subpar result. Take > > if (NILP (XCDR (tail)) && STRINGP (XCAR (tail))) > > for example, it’s parsed as a function definition and all the tokens in the condition are parsed as weird things like macro declarator, error, function declarator, type, etc. And if the condition changes to something else, say it has another layer of function call, it’ll parse differently. But the top-level construct is 'if', no? Isn't that enough? Also, can we detect the FOR_EACH_TAIL etc. macros themselves, and then treat their body specially? > > Please understand: good support for editing Emacs C sources is from my > > POV imperative for c-ts-mode to gain traction. One of my gripes about > > CC Mode was insufficient support for our macro system and for various > > GCC attributes; that improved recently to some extend, but not enough, > > and at a price of introducing ugly lists of strings that cause trouble > > when used in file-local variables. We must do better in c-ts-mode! > > > > So please make an effort of providing reasonable built-in solutions > > for these idiosyncrasies of the Emacs C sources, conditioned on the > > new variable c-ts-mode-emacs-sources-support, at least for those of > > them that are used widely enough. It is very important. > > What do you think of extending the parser to support these macros instead? (So we fork tree-sitter-c.) This goes against the purpose of using tree-sitter and its grammars. I don't think we should maintain and develop language grammars, especially since the production of the C sources from them needs non-trivial system resources and additional tools. Maybe coming up with a way of extending the C grammar in some more general way, and then submitting the changes to the tree-sitter-c developers for inclusion would be OK. But I very much hope that we could support these macros at a lower cost, by some tailored Lisp. Please give it a try. Even if the result works only for the cases we actually use in our sources, it might be "good enough" for us.