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

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]

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

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

[Eli Zaretskii]

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

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

[Alan Mackenzie]

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.

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

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

[Eli Zaretskii]

> Date: Wed, 15 Nov 2023 22:23:15 +0000
> Cc: Rasmus Villemoes <ravi@prevas.dk>, 67173@debbugs.gnu.org
> From: Alan Mackenzie <acm@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.

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]

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

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

[Alan Mackenzie]

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