GNU bug report logs - #78117
Improve c-ts-mode--c-or-c++-regexp

Previous Next

To reply to this bug, email your comments to 78117 AT debbugs.gnu.org.

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

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

From: Sergey Abdulov <tidesmain <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Improve c-ts-mode--c-or-c++-regexp
Date: Mon, 28 Apr 2025 11:13:31 +0500

Hello!

I ran into a header that uses C++ features but still opens in c-ts-mode.
Link: https://raw.githubusercontent.com/HandmadeMath/HandmadeMath/refs/heads/master/HandmadeMath.h
Therefore I suggest either:
1) Treat any mention of `__cplusplus` macro as a C++ file
2) Or add an `operatorX` pattern where X is one of the C++ operators
(don't forget <=> etc)

For now I'm enabling c++-ts-mode manually whenever I edit said header
but it's still bad since some of the broken highlighting from
c-ts-mode persists into c++-ts-mode after toggling and gets fixed
after moving the cursor through affected areas. That's another bug
though.

Thanks!

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sergey Abdulov <tidesmain <at> gmail.com>
Cc: 78117 <at> debbugs.gnu.org
Subject: Re: bug#78117: Improve c-ts-mode--c-or-c++-regexp
Date: Mon, 28 Apr 2025 18:52:40 +0300

> From: Sergey Abdulov <tidesmain <at> gmail.com>
> Date: Mon, 28 Apr 2025 11:13:31 +0500
> 
> Hello!
> 
> I ran into a header that uses C++ features but still opens in c-ts-mode.
> Link: https://raw.githubusercontent.com/HandmadeMath/HandmadeMath/refs/heads/master/HandmadeMath.h
> Therefore I suggest either:
> 1) Treat any mention of `__cplusplus` macro as a C++ file

That's not a good idea, because many header files are basically C
code, but use __cplusplus condition to allow C++ code include the
header file.

> 2) Or add an `operatorX` pattern where X is one of the C++ operators
> (don't forget <=> etc)

That could be unreliable, I'm afraid.

> For now I'm enabling c++-ts-mode manually whenever I edit said header

The usual technique is to have

  // -*- c++ -*-

on the first line of the file.

> but it's still bad since some of the broken highlighting from
> c-ts-mode persists into c++-ts-mode after toggling and gets fixed
> after moving the cursor through affected areas. That's another bug
> though.

Please submit a separate bug about that, with the details: where in
that file do you see the incorrect highlighting after switching the
mode.

Thanks.

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

From: Sergey Abdulov <tidesmain <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78117 <at> debbugs.gnu.org
Subject: Re: bug#78117: Improve c-ts-mode--c-or-c++-regexp
Date: Mon, 28 Apr 2025 22:46:01 +0500

> That's not a good idea, because many header files are basically C
> code, but use __cplusplus condition to allow C++ code include the
> header file.

I mean, after `__cplusplus` check usually comes `extern "C"`
which is not C and won't compile with GCC.
But you have a point so I won't argue.

> That could be unreliable, I'm afraid.

Not sure why. Is there any conflict with C by
matching, say, "operator<" in your opinion?

> Please submit a separate bug about that, with the details: where in
> that file do you see the incorrect highlighting after switching the
> mode.

Working on that. It turns out the issue is still there even if loading
straight into c++-ts-mode. Random curly braces get
`font-lock-warning-face` for no apparent reason.
I'll try to narrow it down as much as possible and report it.

Thanks.

On Mon, Apr 28, 2025 at 10:39 PM Sergey Abdulov <tidesmain <at> gmail.com> wrote:
>
> > That's not a good idea, because many header files are basically C
> > code, but use __cplusplus condition to allow C++ code include the
> > header file.
>
> I mean, after `__cplusplus` check usually comes `extern "C"`
> which is not C and won't compile with GCC.
> But you have a point so I won't argue.
>
> > That could be unreliable, I'm afraid.
>
> Not sure why. Is there any conflict with C by
> matching, say, "operator<" in your opinion?
>
> > Please submit a separate bug about that, with the details: where in
> > that file do you see the incorrect highlighting after switching the
> > mode.
>
> Working on that. It turns out the issue is still there even if loading
> straight into c++-ts-mode. Random curly braces get
> `font-lock-warning-face` for no apparent reason.
> I'll try to narrow it down as much as possible and report it.
>
> Thanks.
>
> On Mon, Apr 28, 2025 at 8:53 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Sergey Abdulov <tidesmain <at> gmail.com>
> > > Date: Mon, 28 Apr 2025 11:13:31 +0500
> > >
> > > Hello!
> > >
> > > I ran into a header that uses C++ features but still opens in c-ts-mode.
> > > Link: https://raw.githubusercontent.com/HandmadeMath/HandmadeMath/refs/heads/master/HandmadeMath.h
> > > Therefore I suggest either:
> > > 1) Treat any mention of `__cplusplus` macro as a C++ file
> >
> > That's not a good idea, because many header files are basically C
> > code, but use __cplusplus condition to allow C++ code include the
> > header file.
> >
> > > 2) Or add an `operatorX` pattern where X is one of the C++ operators
> > > (don't forget <=> etc)
> >
> > That could be unreliable, I'm afraid.
> >
> > > For now I'm enabling c++-ts-mode manually whenever I edit said header
> >
> > The usual technique is to have
> >
> >   // -*- c++ -*-
> >
> > on the first line of the file.
> >
> > > but it's still bad since some of the broken highlighting from
> > > c-ts-mode persists into c++-ts-mode after toggling and gets fixed
> > > after moving the cursor through affected areas. That's another bug
> > > though.
> >
> > Please submit a separate bug about that, with the details: where in
> > that file do you see the incorrect highlighting after switching the
> > mode.
> >
> > Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sergey Abdulov <tidesmain <at> gmail.com>
Cc: 78117 <at> debbugs.gnu.org
Subject: Re: bug#78117: Improve c-ts-mode--c-or-c++-regexp
Date: Tue, 29 Apr 2025 08:15:44 +0300

> From: Sergey Abdulov <tidesmain <at> gmail.com>
> Date: Mon, 28 Apr 2025 22:46:01 +0500
> Cc: 78117 <at> debbugs.gnu.org
> 
> > That's not a good idea, because many header files are basically C
> > code, but use __cplusplus condition to allow C++ code include the
> > header file.
> 
> I mean, after `__cplusplus` check usually comes `extern "C"`
> which is not C and won't compile with GCC.
> But you have a point so I won't argue.
> 
> > That could be unreliable, I'm afraid.
> 
> Not sure why. Is there any conflict with C by
> matching, say, "operator<" in your opinion?

The search for this should take care not to produce false positives,
which might not be easy.  As a trivial example, it should not match
inside comments and strings, and not inside preprocessor directives
that are never true, like "#if 0" or somesuch.

Feel free to submit patches which would search for patterns that are
telltale C++, but I think it is not a coincidence that neither CC Mode
nor c-ts-mode go beyond very simple checks, and leave the rest to the
mode cookie.  (Btw, you could also solve this for an entire directory
using a .dir-locals.el file.  GDB sources do that, for example.)

> > Please submit a separate bug about that, with the details: where in
> > that file do you see the incorrect highlighting after switching the
> > mode.
> 
> Working on that. It turns out the issue is still there even if loading
> straight into c++-ts-mode. Random curly braces get
> `font-lock-warning-face` for no apparent reason.
> I'll try to narrow it down as much as possible and report it.

This could be some issue with the version of the C++ grammar library
you have.  Maybe it's too old, or too new with changes that Emacs did
not yet incorporate.

Previous Next

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