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

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 67173 in the body.
You can then email your comments to 67173 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: Rasmus Villemoes <ravi <at> prevas.dk>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; support raw string literals in C mode (a GNU C extension)
Date: Tue, 14 Nov 2023 11:30:53 +0100

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.

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.

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --enable-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --build
 x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd
 --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --with-cairo
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2
 -ffile-prefix-map=/build/emacs-WL9mhG/emacs-27.1+1=.
-fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD
JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_DK.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: C/*l

Minor modes in effect:
  shell-dirtrack-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  cscope-minor-mode: t
  desktop-save-mode: t
  display-time-mode: t
  electric-pair-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rasmus Villemoes <ravi <at> prevas.dk>, Alan Mackenzie <acm <at> muc.de>
Cc: 67173 <at> debbugs.gnu.org
Subject: Re: bug#67173: 27.1;
 support raw string literals in C mode (a GNU C extension)
Date: Wed, 15 Nov 2023 15:03:39 +0200

> 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 <at> 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.
> 
> 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.

Alan, are you looking into this?

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Rasmus Villemoes <ravi <at> prevas.dk>, 67173 <at> debbugs.gnu.org
Subject: Re: bug#67173: 27.1; support raw string literals in C mode (a GNU C
 extension)
Date: Wed, 15 Nov 2023 22:23:15 +0000

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 <at> 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.

> > 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.

> 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.  I suppose I could add an option into C Mode so that
raw strings can be enabled only when they're needed, but this would be
quite awkward, and a new departure for CC Mode.

-- 
Alan Mackenzie (Nuremberg, Germany)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: ravi <at> prevas.dk, 67173 <at> debbugs.gnu.org
Subject: Re: bug#67173: 27.1; support raw string literals in C mode (a GNU C
 extension)
Date: Thu, 16 Nov 2023 07:57:40 +0200

> Date: Wed, 15 Nov 2023 22:23:15 +0000
> Cc: Rasmus Villemoes <ravi <at> prevas.dk>, 67173 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > > 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.
> 
> > 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.  I suppose I could add an option into C Mode so that
> raw strings can be enabled only when they're needed, but this would be
> quite awkward, and a new departure for CC Mode.

We could support fontification of raw strings only when
font-lock-maximum-decoration is set, or something.  Any solution that
makes this optional behavior is okay from where I stand, since I don't
believe raw string literals will be used frequently enough to make
this a UX issue.

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

From: Rasmus Villemoes <ravi <at> prevas.dk>
To: Alan Mackenzie <acm <at> muc.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 67173 <at> debbugs.gnu.org
Subject: Re: bug#67173: 27.1; support raw string literals in C mode (a GNU C
 extension)
Date: Thu, 16 Nov 2023 09:25:58 +0100

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 <at> 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

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

From: Alan Mackenzie <acm <at> muc.de>
To: Rasmus Villemoes <ravi <at> prevas.dk>
Cc: acm <at> muc.de, Eli Zaretskii <eliz <at> gnu.org>, 67173 <at> debbugs.gnu.org,
 control <at> debbugs.gnu.org
Subject: Re: 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 <at> 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).

Previous Next

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