Comments on #define are not highlighted

Question

Comments on #define are not highlighted

cjastone opened this issue 6 years ago · comments

Chris Stone commented 6 years ago

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

Comments on a line that starts with #define are not highlighted

Steps to Reproduce

Create a line of code with #define (e.g. #define MY_VAR 123) and add a comment to the end (either // comment or /* comment */
Observe that comment is not highlighted correctly.

Expected behavior: Comment is dark grey and italicised.

Actual behavior: Comment remains default light grey and non-italicised.

Reproduces how often: Consistently for the above example.

Versions

Atom : 1.32.0
Electron: 2.0.9
Chrome : 61.0.3163.100
Node : 8.9.3
Windows 10 x64 1803

Robert Sese · Answer 1 · Tue Oct 30 2018 14:24:46 GMT+0800 (China Standard Time)

Thanks for the report! Confirmed on macOS 10.12.6 with 1.34.0-nightly5.

Jeff Hufford · Answer 2 · Wed Oct 31 2018 04:02:21 GMT+0800 (China Standard Time)

I commented in this issue that in 1.32.0 syntax highlighting is broken when Use Tree Sitter Parsers is enabled. What I'm seeing is similar to what's described by OP in that issue, but for C what happens is highlighting gets messed up when #ifdefs are present.

Not sure if this is related to this issue, or is a new issue, so commenting here first. I'm guessing it might be related since, for example, if you do:

#if 0
void someCodeHere(void);
#endif

In 1.31.2 and earlier that code will be grayed-out. But in 1.32.0 it is just black text when Use Tree Sitter Parsers is ticked. When unticked it looks as it should.

Max Brunsfeld · Answer 3 · Wed Oct 31 2018 04:28:11 GMT+0800 (China Standard Time)

@cjastone This issue was fixed via 2302f78, which will ship in Atom 1.32.1, today or tomorrow.

Max Brunsfeld · Answer 4 · Wed Oct 31 2018 04:31:44 GMT+0800 (China Standard Time)

@someburner Yeah, that is a known change due to our new parsing system. It is possible for us to fix, but probably not a super high priority, because it was never a very general behavior. The old parser was just hard-coded to look for #if 0, (as opposed to actually determining if the macro evaluated to false), which would be much more generally useful.

For the time being, if that behavior is very useful to you, you can keep it by unchecking the Use Tree-sitter Parsers checkbox, but we are moving away from maintaining the old parsers, because the new parsers fix a large number of issues. For example, we can finally highlight types and struct fields consistently, which we never could do before.

Max Brunsfeld · Answer 5 · Wed Oct 31 2018 05:11:41 GMT+0800 (China Standard Time)

You can also fold #ifdef blocks now, which you usually couldn't do before because the contents are not traditionally indented.

Jeff Hufford · Answer 6 · Wed Oct 31 2018 05:30:31 GMT+0800 (China Standard Time)

Okay maybe my issue is different and/or related to the syntax I'm using (fizzy).

With Treesitter ticked, I get the following two issues:

1: built-in types not highlighted correctly (int, bool, etc)

2: Multi-line macros do not highlight

I can make a new issue if needed.

Edit: And actually you can see even more issues, like the % not being red. I do see the struct member definitions change color but to me that is a very minor improvement at the cost of these other things not working anymore.

Linus Eriksson · Answer 7 · Wed Oct 31 2018 05:35:02 GMT+0800 (China Standard Time)

@someburner Please make a new issue and include the code in text so we can take a look, thanks 🙇

Max Brunsfeld · Answer 8 · Wed Oct 31 2018 05:36:24 GMT+0800 (China Standard Time)

The multi line macro thing is already fixed.

Max Brunsfeld · Answer 9 · Wed Oct 31 2018 05:37:34 GMT+0800 (China Standard Time)

What theme are you using? Can you compare with the built in ‘one light syntax’ theme? The highlighting of types used to only work for built in types, but now should work for all types.

Jeff Hufford · Answer 10 · Wed Oct 31 2018 05:41:39 GMT+0800 (China Standard Time)

I'm using this one: https://github.com/jglovier/fizzy

But these issues are also present when using standard themes like "Atom Light".

A good example to see the behavior is: https://github.com/nodejs/http-parser/blob/master/http_parser.h

Expected highlighting would be what it looks like in the browser on github. But in Atom it looks like:

Max Brunsfeld · Answer 11 · Wed Oct 31 2018 05:51:58 GMT+0800 (China Standard Time)

👍 Yeah, agreed. When I said that issue was "already fixed", I mean that the bug has been fixed, but the fix has not yet been published. We're working on getting Atom 1.32.1 out right now.

Jeff Hufford · Answer 12 · Wed Oct 31 2018 05:53:15 GMT+0800 (China Standard Time)

Ah, okay thanks. I'll wait for 1.32.1 and see how it goes.

Max Brunsfeld · Answer 13 · Wed Oct 31 2018 05:54:47 GMT+0800 (China Standard Time)

But actually, the issue that's fixed is just the macro body thing. I am still curious about any problems you're seeing with types being highlighted, because as far as I know, that should work on 1.32. Does that problem show up for you on the default theme?

Jeff Hufford · Answer 14 · Wed Oct 31 2018 06:00:28 GMT+0800 (China Standard Time)

Yeah actually only with fizzy. But when Treesitters is unticked it does highlight. Are there some new directives needed to get that working? I'm a CSS noob :)

Max Brunsfeld · Answer 15 · Wed Oct 31 2018 06:03:34 GMT+0800 (China Standard Time)

Hmm, I'll take a look; our intention was to maintain compatibility with most themes in general use, so sorry about that. Maybe there's some extra classes we can add. Unfortunately, that work won't make it into 1.32.1, but it's on our radar.

Chris Stone · Answer 16 · Wed Oct 31 2018 12:52:26 GMT+0800 (China Standard Time)

Thanks @maxbrunsfeld - have the update and this is back to normal, keep up the great work everyone!

Linus Eriksson · Answer 17 · Wed Oct 31 2018 16:02:15 GMT+0800 (China Standard Time)

Seems like this is because some of the primitive types are scoped as support.support.type instead of support.storage.type. I opened a PR.