Escaped characters in format strings in C are not being highlighted with the new tree-sitter parser

[ghost]

@prati0100 commented on Nov 1, 2018, 4:45 PM UTC:

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

When using %s, %d, etc the %s part is not highlighted in tree-sitter parser. Without tree-sitter they are highlighted. I thought it would belong better in atom/language-c, but then I checked the scopes, and they are different with tree-sitter and without, so I'm guessing this is a better place. Apologies if it isn't.

Steps to Reproduce

1. Use escaped characters like %d, %s in format strings.

Expected behavior: The escaped characters should be highlighted differently from the rest of the string

Scope:

• source.c
• meta.block.c
• string.quoted.double.c
• constant.other.placeholder.c

Actual behavior: They are not highlighted

Scope:

• source.c
• string.quoted.double

Reproduces how often: 100%

Versions

atom --version:
Atom : 1.32.1
Electron: 2.0.9
Chrome : 61.0.3163.100
Node : 8.9.3

apm --version:
apm 2.1.2
npm 6.2.0
node 8.9.3 x64
atom 1.32.1
python 2.7.12
git 2.18.0

OS:
Ubuntu 16.04

Kernel:
Linux 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

This issue was moved by rsese from atom/atom#18380.

[rsese]

Thanks for the report @prati0100! Another maintainer mentioned that this seems like the same issue referenced in atom/language-go#158 (review) which ties into a higher-level (not just C-specific) issue at atom/atom#18196.

Feel free to subscribe to atom/atom#18196 if for updates you'd like and we'll keep this open for now.