bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alan Mackenzie
Subject: bug#67173: 27.1; support raw string literals in C mode (a GNU C extension)
Date: Wed, 16 Oct 2024 14:01:18 +0000

tags 67173 + wontfix
close 67173
quit

Hello, Rasmus.

In the end, I decided not to implement raw strings in C Mode.  The
reasons are:
(i) They are a pure GCC extension, undocumented in its manual, and used
  vanishingly rarely.
(ii) Raw strings would slow C Mode down.
(iii) A user option to enable them would be the only such option in CC
  Mode which selects language features to implement.  This would jar
  aesthetically, and likely lead to maintenance headaches.

So, sorry about that, but thank you all the same for taking the trouble
to submit the original bug report.

On Thu, Nov 16, 2023 at 09:25:58 +0100, Rasmus Villemoes wrote:
> 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

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]