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.

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.

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.

Yes, that sounds good.

Thanks,

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

Workaround: uncheck "Use Tree Sitter Parsers"

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

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.