GNU bug report logs - #70272
30.0.50; Refactor c-ts-mode

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 70272 in the body.
You can then email your comments to 70272 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Bug Report Emacs <bug-gnu-emacs <at> gnu.org>
Subject: 30.0.50; Refactor c-ts-mode
Date: Mon, 8 Apr 2024 00:17:54 -0700

X-Debbugs-CC: eliz <at> gnu.org <mailto:eliz <at> gnu.org>

Eli, I’m finding c-ts-mode to get uglier and heavier in an unfortunate rate. Of course, I’m basically the defector maintainer now and the main person to blame for much of the complexity. We needed to add a lot of code and even hacks to make c-ts-mode work for complex C code.

A complicated and sometimes hacky c-ts-mode.el is bad for maintainability, and sometimes make c-ts-mode slow and unpleasant to use. More over, I feel that some people will look at c-ts-mode when looking for an example for writing a tree-sitter major mode. And c-ts-mode in its current state is not very suitable as an example.

Since a lot of the complexity are only needed by complex C code. I wonder if we can separate c-ts-mode.el into a simpler version that works for “modern” C and C++, plus an extra file that contains the additional things that makes it work for complex C code?

Yuan

Message #10 received at 70272 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Yuan Fu <casouri <at> gmail.com>
Cc: eliz <at> gnu.org, 70272 <at> debbugs.gnu.org
Subject: Re: bug#70272: 30.0.50; Refactor c-ts-mode
Date: Fri, 28 Feb 2025 18:52:35 -0800

Yuan Fu <casouri <at> gmail.com> writes:

> X-Debbugs-CC: eliz <at> gnu.org <mailto:eliz <at> gnu.org>
>
> Eli, I’m finding c-ts-mode to get uglier and heavier in an unfortunate rate. Of
> course, I’m basically the defector maintainer now and the main person to blame
> for much of the complexity. We needed to add a lot of code and even hacks to
> make c-ts-mode work for complex C code.
>
> A complicated and sometimes hacky c-ts-mode.el is bad for maintainability, and
> sometimes make c-ts-mode slow and unpleasant to use. More over, I feel that some
> people will look at c-ts-mode when looking for an example for writing a
> tree-sitter major mode. And c-ts-mode in its current state is not very suitable
> as an example.
>
> Since a lot of the complexity are only needed by complex C code. I wonder if we
> can separate c-ts-mode.el into a simpler version that works for “modern” C and
> C++, plus an extra file that contains the additional things that makes it work
> for complex C code?

I'm also lacking some detail here: what exactly is considered "complex C
code"?  Why is it better if we move things to a separate mode?  We still
have to maintain it, right?

If we want to make any such changes, I think the idea should be
discussed on emacs-devel.

Message #13 received at 70272 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: eliz <at> gnu.org, 70272 <at> debbugs.gnu.org
Subject: Re: bug#70272: 30.0.50; Refactor c-ts-mode
Date: Wed, 5 Mar 2025 07:04:14 -0800

> On Feb 28, 2025, at 6:52 PM, Stefan Kangas <stefankangas <at> gmail.com> wrote:
> 
> Yuan Fu <casouri <at> gmail.com> writes:
> 
>> X-Debbugs-CC: eliz <at> gnu.org <mailto:eliz <at> gnu.org>
>> 
>> Eli, I’m finding c-ts-mode to get uglier and heavier in an unfortunate rate. Of
>> course, I’m basically the defector maintainer now and the main person to blame
>> for much of the complexity. We needed to add a lot of code and even hacks to
>> make c-ts-mode work for complex C code.
>> 
>> A complicated and sometimes hacky c-ts-mode.el is bad for maintainability, and
>> sometimes make c-ts-mode slow and unpleasant to use. More over, I feel that some
>> people will look at c-ts-mode when looking for an example for writing a
>> tree-sitter major mode. And c-ts-mode in its current state is not very suitable
>> as an example.
>> 
>> Since a lot of the complexity are only needed by complex C code. I wonder if we
>> can separate c-ts-mode.el into a simpler version that works for “modern” C and
>> C++, plus an extra file that contains the additional things that makes it work
>> for complex C code?
> 
> I'm also lacking some detail here: what exactly is considered "complex C
> code"?  

We makes a lot of effort to support macros that are specific to Emacs’s C source in c-ts-mode.el, think FOR_EACH_TAIL and DEFUN. Simpler C code only use macros that looks like a funcall, which are a lot easier to support.

> Why is it better if we move things to a separate mode?  We still
> have to maintain it, right?

Right. Part of the reason is that sometimes people look at c-ts-mode’s implementation as a reference, since C is kind of the staple language, and most modern languages share similar syntax. So a simple and clean c-ts-mode.el can help in that regard.

> If we want to make any such changes, I think the idea should be
> discussed on emacs-devel.

Since then I’ve made some effort to restructure the code, and organized the indentation rules a bit. So I’m much happier about c-ts-mode.el now. I think we can close this.

Yuan

Message #18 received at 70272-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: stefankangas <at> gmail.com, 70272-done <at> debbugs.gnu.org
Subject: Re: bug#70272: 30.0.50; Refactor c-ts-mode
Date: Wed, 05 Mar 2025 17:24:43 +0200

> From: Yuan Fu <casouri <at> gmail.com>
> Date: Wed, 5 Mar 2025 07:04:14 -0800
> Cc: 70272 <at> debbugs.gnu.org,
>  eliz <at> gnu.org
> 
> > Why is it better if we move things to a separate mode?  We still
> > have to maintain it, right?
> 
> Right. Part of the reason is that sometimes people look at c-ts-mode’s implementation as a reference, since C is kind of the staple language, and most modern languages share similar syntax. So a simple and clean c-ts-mode.el can help in that regard.

Would adding comments to the "unclean" code there help in this regard?

> > If we want to make any such changes, I think the idea should be
> > discussed on emacs-devel.
> 
> Since then I’ve made some effort to restructure the code, and organized the indentation rules a bit. So I’m much happier about c-ts-mode.el now. I think we can close this.

Thanks, done.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.