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#62951: 29.0.90; c-ts-mode: Incorrect fontification due to FOR_EACH_TAIL_SAFE Date: Sat, 22 Apr 2023 17:28:25 -0700 Message-ID: <2BDA88D0-A870-4FE3-BAF8-350FBAA943BF@gmail.com> References: <82E7ADEC-25BC-475B-8EE0-839FE78FF2F4@gmail.com> <83fs8s2xnk.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) 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="38768"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62951@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 23 02:29:22 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 1pqNbW-0009vy-JT for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 23 Apr 2023 02:29:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pqNbE-0003CI-Si; Sat, 22 Apr 2023 20:29:04 -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 1pqNbD-0003C3-Ho for bug-gnu-emacs@gnu.org; Sat, 22 Apr 2023 20:29: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 1pqNbC-0004wK-AC for bug-gnu-emacs@gnu.org; Sat, 22 Apr 2023 20:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pqNbB-0007wj-Kq for bug-gnu-emacs@gnu.org; Sat, 22 Apr 2023 20:29:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 23 Apr 2023 00:29:01 +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.168220972930522 (code B ref 62951); Sun, 23 Apr 2023 00:29:01 +0000 Original-Received: (at 62951) by debbugs.gnu.org; 23 Apr 2023 00:28:49 +0000 Original-Received: from localhost ([127.0.0.1]:44335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pqNay-0007wD-Hj for submit@debbugs.gnu.org; Sat, 22 Apr 2023 20:28:48 -0400 Original-Received: from mail-pf1-f179.google.com ([209.85.210.179]:62586) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pqNau-0007vn-0d for 62951@debbugs.gnu.org; Sat, 22 Apr 2023 20:28:47 -0400 Original-Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-63d4595d60fso21083245b3a.0 for <62951@debbugs.gnu.org>; Sat, 22 Apr 2023 17:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682209718; x=1684801718; 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=UqMMf6KdY70TMRKXGdifmvdwKjjo7fY7CB6kXB8wREk=; b=bNvJnThYFSBO5KCNgrFh/94nUIsWWOy4C8K6evzK51h2S4ODaCKeznO1OYKErZUP2j QuIidZePz+Sf6/g8CMwEwcwO1B5c4iMRdXbBNvB11lxvoiKhpdUmj5xvbvvuTTsvtPpD LxT0thRSnM1rX53i4LWNf3kmBSWcqpQ6cMY+M1UEoPUtEL7KZcAe6HkY7dP8sNA85uFu zhwpaMMsWGt+FgfeoIwtpf554Vy0AYIFV1eqmIJHmnQ9Vy+kpF1kTa3c3THSnXDVSzZi pLMrgaZqhfBl1dxCy6GuBKoiTqKLzGzFt+dBt6N6ksdiqgnW0vzgIu5EI+1ERD+idHXB McHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682209718; x=1684801718; 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=UqMMf6KdY70TMRKXGdifmvdwKjjo7fY7CB6kXB8wREk=; b=TQZChq1W8oLIyeJ2jkEWBObXu5ShjI8PZUbtfeg5cgWnMTi6EP9p7oiJ9pHeY4g4ME mnidk8qajjGmk6yreLSTz2vDgKxVO079Hq11aOACh47jOvtKZod3aikmRMjFnoZ83lAq l6QI7X2kauoecsnsL/vU963Pzd9GthwKSg1JNo8qSZo227XJ4AukShiMK+u39BChcLyA 8hE8bXXQG7YjJRpvavIWf38f/ArJF9yI07pwEk664sJU2V0ZPbdK6Dk9f29A+apOT1gQ 1rWmUJF37zIBt1K+3G3jMyW0KA14k3PNWlEy5CcQYKqSLxJhH1bRWHgxmkvcv9QS5EI1 sZRw== X-Gm-Message-State: AAQBX9dJ1Lp0LXi8WQDlEy/SRkhPfTEHP8cMe8hcp0aUhXAO8ETDSgB7 uVyYB3nOSD2oeKVr39gssqi+9SaV7GhmUg== X-Google-Smtp-Source: AKy350a1rmpbuEsfWcLJv4oL2q7j9Tt1s+9Vzu6YsUbIJyVXt344xkLrlyqxv6B3NhI1lUiPi9HaIw== X-Received: by 2002:a17:902:e752:b0:1a6:6bd4:cd8c with SMTP id p18-20020a170902e75200b001a66bd4cd8cmr10696410plf.25.1682209717698; Sat, 22 Apr 2023 17:28:37 -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 f2-20020a170902ab8200b001a0448731c2sm4483320plr.47.2023.04.22.17.28.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Apr 2023 17:28:37 -0700 (PDT) In-Reply-To: <83fs8s2xnk.fsf@gnu.org> X-Mailer: Apple Mail (2.3731.500.231) 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:260490 Archived-At: > On Apr 22, 2023, at 12:17 AM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Fri, 21 Apr 2023 13:37:08 -0700 >> Cc: 62951@debbugs.gnu.org >>=20 >>=20 >> Eli Zaretskii writes: >>=20 >>> To reproduce: >>>=20 >>> emacs -Q >>> C-x C-f src/fns.c RET >>> C-u 3365 M-g g >>>=20 >>> Observe that "if" and "STRINGP" in the body of FOR_EACH_TAIL_SAFE = are >>> fontified in font-lock-function-name-face. This is because the >>> FOR_EACH_TAIL_SAFE macro is misparsed by tree-sitter as a = declaration. >>>=20 >>> Can we teach c-ts-mode to recognize FOR_EACH_TAIL_SAFE and >>> FOR_EACH_TAIL for what they are, perhaps conditioned on >>> c-ts-mode-emacs-sources-support being non-nil? >>=20 >> I=E2=80=99m aware of this issue, but the truth is there isn=E2=80=99t = 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=E2=80=99s a if statement, with = macro calls >> and AND operation in it=E2=80=99s condition, it=E2=80=99s 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 :-) >=20 > 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: >=20 > . 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) >=20 > (In practice, only the first 2 and the last one are used, AFAICS.) >=20 > 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=E2=80=99s a lot of dirty code for a subpar result. Take if (NILP (XCDR (tail)) && STRINGP (XCAR (tail))) for example, it=E2=80=99s 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=E2=80=99ll parse differently. >=20 >> We can probably fix this very particular case, but it=E2=80=99s still = work and >> overhead, and doesn=E2=80=99t mean much. >=20 > 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! >=20 > 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.) If we can fix the parser, we = don=E2=80=99t need to retrofit hacks onto font-lock, indent, etc, = separately, and it truly fixes the problem. The downside is compiling = from grammar source to grammar.c needs rust and node tools. But I guess = depending on the grammar maintained by tree-sitter=E2=80=99s author = isn=E2=80=99t too much different from depending on the grammar = maintained by another individual (ie, me)? Yuan=