Non italics text treated as italics after C code block

[g199209]

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

In C language, /* */ stands for comment. But in some case, if we use /* */ in code block, * will be treated as italics begin. This only happen in C or Cpp code block, Java and C# code block do not have this matter.

Steps to Reproduce

1. Change the file highlight to Github Markdown.
2. type the following code in a C code block respectively. (See the screenshot below)

{
/* comment */
}

/* comment */

Only the first format will cause some matter. That means /* */ in { }scope.

Expected behavior: [What you expect to happen]

These two code segments are both correct, and the text after the code block should not be italic.

{
    /* comment */
}

This line should not be italic.

    /* comment */

This line should not be italic.

Actual behavior: [What actually happens]

Non italics text treated as italics in first format.

If we delete the first {, the highlight is correct.

---

And if we change the language of the code block from c to java or c#, this problem do not happen.

Reproduces how often: [What percentage of the time does it reproduce?]

Always.

Versions

Atom : 1.21.0
Electron: 1.6.9
Chrome : 56.0.2924.87
Node : 7.4.0

apm 1.18.5
npm 3.10.10
node 6.9.5 x64
python 3.5.1
git 2.9.3.windows.3
visual studio 2015

OS: Windows 10 64 bit

Additional Information

There are some similar issues:

#198
#133
#171

But this problem still not solved...

[danziamo]

Not exactly, but i think i also have related problem with javascript because of curly bracket

[dead-claudia]

BTW, I'm still reproducing this in safe mode, following the original repro steps. It's basically destroyed formatting for a couple of my files, and my current workaround is to just disable highlighting of that code block (the offending C/C++-specific highlighting issues are all in a private personal repo).

Here's my version info:

$ atom --version
Atom    : 1.36.0
Electron: 2.0.18
Chrome  : 61.0.3163.100
Node    : 8.9.3

$ apm --version
apm  2.1.3
npm  6.2.0
node 8.9.3 x64
atom 1.36.0
python 2.7.10
git 2.17.2

[dead-claudia]

My theory is that the C code isn't being matched greedily enough, and between that and the looseness of C's grammar itself, it's confusing the syntax highlighter.

[Aerijo]

@isiahmeadows I believe the cause is that the C++ grammar crosses with the C grammar in places, and this crossing method uses a reference to the base grammar of the file. I haven’t had any part on writing those grammars, so can’t comment on how necessary this is, but I recall it being a known issue.

In normal C++ files the base grammar is C++, so it all works, but in a markdown codeblock the base is markdown. Unfortunately, there does not exist a way to refer to the “parent” grammar.

[dead-claudia]

@Aerijo Are you sure? My example specifically sets C, not C++, and although the C++ grammar explicitly extends the C grammar, the C grammar doesn't depend on any C++ productions. Also, the tree-sitter grammar for C and C++ don't seem to intersect except through rules common across both. (I don't think the GFM grammar has a tree-sitter variant, though.)

[Aerijo]

@isiahmeadows Yes, the C grammar uses $base to insert the rules of whatever grammar might have been using it (which includes the C grammar itself, as in your case). Specifically, now I'm looking at the grammar, this line gives the block innards rules. Note the comments are not specified; they are left to be included by $base, which points to the wrong grammar in the code block. So effectively C comments don't exist in that { ... } section as far as the grammar is concerned.

The Tree-sitter grammar is irrelevant, as only same kind grammars can be embedded in each other currently and language-gfm is still TextMate only.

[dead-claudia]

@Aerijo Oh okay. I didn't realize that part, nor did I know what $base did. (It's subtly different than what I was referring to, though.)

So should I file a bug against language-c then, referencing this bug?

[Aerijo]

@isiahmeadows Looks like one already exists. I think it's been known for a while, and I appear to have referenced that issue before, but the problem is that the editor TextMate also has that bug, and the grammar engine was designed to be compliant with TextMate.

[dead-claudia]

I wrote this comment over in that bug. Should this be closed as a dupe of that, since it predated this by over a year (and nothing new has since arisen)?

[whatsrtos]

also pointer in C code block