Languages c and cpp improvements #875
Conversation
I think it's fine for the c syntax to take over .h (don't know what .inl is) since while it does support both c++ and c, most of the time it'll be c syntax and anyone who wants it to be c++ will change it |
I remember some one complaining on discord about c++ syntax not working right and it was because of this which isn't obvious. If we distribute both C and C++ language files they should not step on the shoes of the others, that would be useless. Besides, the C++ language file provides all that C provides. But, there would be extra colorization on your .h with C code if you use C++ identifiers 😉 . This is the price to pay for developers using .h files for both C and C++. |
jgmdev
force-pushed
the
language-c-cpp-improvements
branch
2 times, most recently
from
3c57cdb
to
ae545df
Compare
* Removed pcall(require, "plugins.language_c") since it doesn't works as it seems to have been intended. * Removed duplicate keywords * Added support for magic and uppercase constants. * Basically merged most changes from the lite-xl-plugins repo.
* Do not compete with language_cpp.lua over the .h and .inl files, these files can contain both cpp and c so we choose the former which supports both syntaxes. * Added support for magic and uppercase constants.
jgmdev
force-pushed
the
language-c-cpp-improvements
branch
from
ae545df
to
b880aa4
Compare
|
Merging this since previous behavior wasn't even working right and the tokenizer requiring patterns to be specified into certain order to properly work would mean that overriding the c syntax from within cpp syntax would result on undefined highlighting behavior. Testing so far on lite-xl source which is C and nothing seems to break and instead we gain proper cpp support on .h files. if one would like to force explicit C only syntax on a specific .h file can use the force_syntax.lua plugin |
language_cpp:
language_c: