@ntrel pushed 1 commit.

e079381556b8ce8a3a1fcdfcf8b572ec0f303c10 Add const, signed, unsigned, void

Also added const as it may as well include type modifiers.

Actually for C++ these are all reserved [keywords](https://en.cppreference.com/w/cpp/keyword), so should be in the primary list with the other keywords.

If you are going to include qualifiers then it should include `volatile` `constinit` `constexpr` `constexpr` `mutable`, and what about `alignas` (`_Alignas` in C).

But `const` and several of those can also be used in non-CV qualification context as well[^1], so since Scintilla can't detect context they will be wrongly coloured in one context or the other. Only treating them as a keyword is context free and fits the Scintilla model.

So separating some keywords from others is not the right thing to do for C++, so this PR should not happen.

Might be ok for C since it tends not to re-use keywords in more than one context, but C23 adds a lot more built-in types, [see](https://en.cppreference.com/w/c/keyword) but again they are keywords.

[^1]: C++ has a tendency to re-use keywords in other contexts rather than defining new keywords that might clash with valid names in existing code. So over time many keywords are becoming more than one thing (not to mention words that are keywords only in contexts where user names are illegal, eg `override` in:

``` struct S { int override; virtual int foo() = 0; };

struct DS : public S { int foo() override { override = 1; return 2; } }; ``` Geany shows all cases of `override` as keyword, but VScode shows only the `override` after `foo()` as a keyword, and the others as member variables. Thats something the current Geany/uctags/Scintilla combination can't handle).

And C++ avoids using the ugly `_Caps` that C does.

If you are going to include qualifiers then it should include volatile constinit constexpr constexpr mutable, and what about alignas (_Alignas in C).

I don't think those are *type* qualifiers. But I can see it may cause confusion so I'll remove const.

...

If you are going to include qualifiers then it should include volatile constinit constexpr constexpr mutable, and what about alignas (_Alignas in C).

I don't think those are type qualifiers. But I can see it may cause confusion so I'll remove const.

Note I meant `constexpr` and `consteval`, not `constexpr` twice :-P.

In C++ `volatile` is a type qualifier just like `const` in fact the standard talks about [CV qualifiers](https://en.cppreference.com/w/cpp/language/cv) everywhere. Both `constexpr` and `consteval` apply the `const` qualifier to the type plus they specify some semantics as well, so `constexpr int i = expression;` gives `i` type `const int` as well as saying the initialiser _must_ be evaluated at compile time, so its a qualifier++. Oh, and `constexpr` and `consteval` can be applied to `if` statements as well as declarations. C++, its complicated!!!!

So yeah, best to keep the secondary keyword list just as types, they are only ever used with one meaning. And maybe that could be given the same style (`keyword_3` I think) as Geany detected types?

I think it is useful to highlight types from global tag files differently from types in the current workspace.

Just to be clear, for the categories of types:

1. fundamental types, the list proposed in this PR 2. types from tags files, eg C++ STL tags from the wiki 3. types from open files, or generated by plugins for closed files (eg project organiser)

The language actually lists fundamental types as [keywords](https://en.cppreference.com/w/cpp/keyword), so they have the same characteristics, eg you can't redefine `int` in a nested scope as you can for a normal typename. And current filetype styles them as keywords which is technically correct.

We are now suggesting doing it wrong might be more useful, your suggestion have 1. styled as 2., my suggestion have 1. styled as 3.

Not sure, maybe we should just leave well enough alone (ie leave 1. as keyword styles :-)