From: Dmitry Gutov <dmitry@gutov.dev>
To: Yuan Fu <casouri@gmail.com>, Eli Zaretskii <eliz@gnu.org>
Cc: 62951@debbugs.gnu.org
Subject: bug#62951: 29.0.90; c-ts-mode: Incorrect fontification due to FOR_EACH_TAIL_SAFE
Date: Mon, 24 Apr 2023 00:04:02 +0300 [thread overview]
Message-ID: <384f8110-eba6-8fb3-ef4e-56fa0721d85d@gutov.dev> (raw)
In-Reply-To: <2BDA88D0-A870-4FE3-BAF8-350FBAA943BF@gmail.com>
On 23/04/2023 03:28, Yuan Fu wrote:
> 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’t 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’s author isn’t too much different from depending on the grammar maintained by another individual (ie, me)?
We had also talked at some point about replacing the actual text that
the parser sees with something else.
If this can be done in a straightforward way (with tracking the
subsequent correspondence of "real" text back to the buffer for syntax
highlighting), that might be the perfect solution: we'd have a defcustom
which would hold a list of macros used in the current codebase in the
form of templates, and we'd set a bunch of them in emacs/.dir-locals.el.
I'm not sure how difficult this is to implement and maintain, but it's
probably going to be less work to maintain than a fork of the grammar.
next prev parent reply other threads:[~2023-04-23 21:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 16:40 bug#62951: 29.0.90; c-ts-mode: Incorrect fontification due to FOR_EACH_TAIL_SAFE Eli Zaretskii
2023-04-21 20:37 ` Yuan Fu
2023-04-22 7:17 ` Eli Zaretskii
2023-04-23 0:28 ` Yuan Fu
2023-04-23 6:25 ` Eli Zaretskii
2023-04-24 7:02 ` Yuan Fu
2023-04-23 21:04 ` Dmitry Gutov [this message]
2023-04-26 22:19 ` Yuan Fu
2023-04-27 3:14 ` Yuan Fu
2023-04-27 15:03 ` Eli Zaretskii
2023-04-27 19:56 ` Yuan Fu
2023-04-28 5:41 ` Eli Zaretskii
2023-04-29 22:55 ` Yuan Fu
2023-04-30 5:24 ` Eli Zaretskii
2023-04-27 8:57 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=384f8110-eba6-8fb3-ef4e-56fa0721d85d@gutov.dev \
--to=dmitry@gutov.dev \
--cc=62951@debbugs.gnu.org \
--cc=casouri@gmail.com \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).