bug#67173: 27.1; support raw string literals in C mode (a GNU C extension)

[Rasmus Villemoes via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

On 15/11/2023 23.23, Alan Mackenzie wrote:
> Hello, Eli and Rasmus.
> 
> On Wed, Nov 15, 2023 at 15:03:39 +0200, Eli Zaretskii wrote:
>>> Date: Tue, 14 Nov 2023 11:30:53 +0100
>>> From:  Rasmus Villemoes via "Bug reports for GNU Emacs,
>>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
>>> gcc, when using -std=gnu99 or newer, supports using raw string literals
>>> in C code. But emacs' C mode does not do proper syntax highlighting for
>>> that case.
> 
> Thanks!  I didn't know about that.  I can't find any mention of raw
> strings in C in the GCC manual for version 10.3.0.

No, it's not mentioned anywhere, and I don't know why they don't
document it, but it's most definitely deliberate (see the
lang_defaults[] table in libcpp/init.cc).

>>> I do not know if that can be fixed by simply adding
>>> c-before-change-check-raw-strings to C mode's
>>> c-get-state-before-change-functions.
> 
> That's the basic idea, yes, with another function to be added to
> c-before-font-lock-functions.  But there are several detailed changes
> necessary, too.

That explains why my quick hacking didn't work...

>> Alan, are you looking into this?
> 
> I am now.  What's bothering me at the moment is that this is going to
> make C Mode slower.  

Urgh, I didn't think about that. I agree that it's probably not very
widely used (probably partly due to not being documented...). I myself
only use it very rarely, and for now just use C++ mode for the file in
question where I noticed this.

So if "slower" is actually noticeable, I would probably prefer to
retract this bug report or ask that support becomes some explicit
opt-in, because 99.99% of the .c files I touch do not use raw strings.

Regardless, thanks for taking this up so quickly.

Rasmus