Undefined words are highlighted as keywords

[wesinator]

Edit by @rsese: from Max in #308 (comment):

It sounds like you want built-in types (like int) to have a different color than user-defined types (like MyLibraryInteger in the example above). I think that makes sense, but I'd like to keep it as a subtly different color (as opposed to a completely different color), because I think there's a lot of value in coloring types consistently for visual understanding of structure.

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

any word following a preceding keyword is highlighted as a keyword, even if it is not valid

Steps to Reproduce

Consider the following code:

unsigned int y; // correct

// wrong:
unsigned integer x;
inline integer z;

Expected behavior: 'integer' is not highlighted, as it is not a valid keyword
Words following preceding keyword are only highlighted if they are also actual keywords.

Github and VS Code C highlighting does this correctly.

Actual behavior: any word following a preceding keyword is highlighted as a keyword, even if it is not valid

Reproduces how often: Always

Versions

0.60.13
atom 1.32.2

[maxbrunsfeld]

Just to clarify, we're highlighting it as a type, not a keyword. If you use that syntax, integer is indeed a type.

One concrete example is that you can do this:

#ifdef WIN32
#define MyLibraryInteger __int32
#else
#define MyLibraryInteger int32_t
#endif

unsigned MyLibraryInteger MY_LIBRARY_VERSION;

In that case, MyLibraryInteger is a type.

[wesinator]

Ok, it shouldn't highlight the word unless its a defined type.

The problem is this makes it harder to identify that the user typed an invalid type word if any word is highlighted as a type. The example I gave was a real mistake I had made; it would have been easier to spot if the grammar wasn't automatically highlighting the following word.

[maxbrunsfeld]

It sounds like you want built-in types (like int) to have a different color than user-defined types (like MyLibraryInteger in the example above). I think that makes sense, but I'd like to keep it as a subtly different color (as opposed to a completely different color), because I think there's a lot of value in coloring types consistently for visual understanding of structure.

The reason that this "works" with VSCode and GitHub.com is that those syntax highlighters can only ever recognize built-in types, so user-defined types are generally not highlighted at all.

[wesinator]

Yes, that sounds good.

Thanks,

[wesinator]

It seems that any undefined word gets highlighted, whether or not it follows an actual keyword

This is astonishing behaviour that negatively affects code reading and debugging

[wesinator]

Workaround: uncheck "Use Tree Sitter Parsers"

Between this and atom/language-todo#82, I'm going to avoid Tree Sitter for the time being.

[maxbrunsfeld]

Hey @wesinator, thanks for raising this issue and providing good examples. The poor error recovery you're seeing in C is a symptom of a missing Tree-sitter feature. I've opened a PR to add that feature (tree-sitter/tree-sitter#246) and in the coming weeks I'll be updating our C parser to make use of it, eliminating this issue.