Subject: Re: bug#78117: Improve c-ts-mode--c-or-c++-regexp

From: Eli Zaretskii <[email-masked]>
Date: Tue, 29 Apr 2025 08:15:44 +0300

> From: Sergey Abdulov <[email-masked]>
> Date: Mon, 28 Apr 2025 22:46:01 +0500
> Cc: [email-masked]
> 
> > 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.