> Regarding C++ concepts, I recommend the following:
1. In their definition, concept names should be treated like types.
2. When they are used as a placeholder for a type, i.e. "concept_name auto variable_name", then "concept_name auto" should also be highlighted as a type.
3. When they are used as a predicate, i.e. "concept_name<type>" they are essentially an expression that evaluate to true or false and should thus be treated as a variable.
4. When they are used in the "intermediate concept syntax", i.e. "template <concept_name T>", they should get the colour that "typename" usually gets.

Kate has no idea about the text its editing. We rely on 100% on the LSP server to tell us what is what and it tells us that in the form of some predefined values like "keyword", "function" etc and we have colors that correspond to these predefined values. So every language specific thing should be a suggestion/bug/feature request for the LSP server, not kate.

That said, we do lack a couple of things in the coloring part for e.g., the syntax highlighting doesn't have any "variable parameter". For some themes I hardcoded the colors as I saw them in VSCode/other editors for e.g so that they look very similar. For e.g., if you try Monokai, you will likely see colors for T in "template<typename T>". For other themes, the color of T will be the value of "Variable" in the color scheme, so if you change that to orange, you will see orange. For "types,classes, structs, enum", the color of "Data Type" will be used, similarly for functions and methods "Function" color will be used. For macros, "Preprocessor" color is used. For enumerators, color of "Constant" is used.

So you can get most of what you need by just adjusting the color scheme a little bit I think. I know the documentation on how semantic highlighting colors are managed is non-existent, sorry about that, but I tried to give you an idea on how we handle it, hope it helps.

I tried to improve our color schemes to some extent so that they map to their original versions more accurately but that's not true for all the schemes. You will find schemes like Monokai or Dracula will look better / closer to the original variants because I use them and put more effort in improving them, same is not true for the scheme that you are using i.e., Solarized Light if I am right.

Some other things. We ignore a lot of information sent to us by the LSP, for e.g we ignore keyword information or string or number because our syntax highlighter already knows that stuff, no need waste energy on re-highlighting that. We also ignore local variables completely. And finally, we currently ignore all language specific information or "extensions" to the official types defined by the LSP protocol.

If this works for you / helps you, then we can close this as the language specific stuff is out of scope for Kate and should probably be reported clangd (assuming that you are using that)

Thank you for your response, and sorry for my late reply.

I am a little confused. On the one hand, you say that "Kate has no idea about the text its editing" but then you also say "We ignore a lot of information sent to us by the LSP" and "we do lack a couple of things" and then even "For some themes I hardcoded the colors".

This makes it super-difficult for me to actually figure out if 
1) the LSP is sending the wrong information; or
2) Kate's handling of the LSP information is wrong; or
3) The actual *theme* is overwriting something.

What is the recommended procedure for me to figure this out?

I am aware that Kate's syntax highlighting is a lot older than the LSP code, and that it might be difficult to create 1-to-1 mappings for everything, but with LSP being so common nowadays, wouldn't it make sense to adopt the categories (type, variable...) that LSP uses?

Thank you for your help on this!

> I am a little confused. On the one hand, you say that  "Kate has no idea about the text its editing"
> but then you also say "We ignore a lot of
> information sent to us by the LSP" and "we do lack a couple of things" and then even "For some themes I hardcoded the colors".

Let me try to clarify. In a more pedantic sense, kate has very little idea about the text its editing. It does know about comments, strings, keywords. This is basic stuff, so any decent syntax highlighter will be able to parse a document and collect this information. But slightly more complex things such as ... a function, or scope, or what kind of a variable do we have are usually not handled and even if they are, the results might not be very accurate.

The information we ignore is the things we know for sure we already have => language keywords, comments, strings. This is just for efficiency reasons.

The things we lack are
- modifier coloring support. LSP can send info about modifiers which you can use to color things differently.
- some clangd specific things IIRC

> This makes it super-difficult for me to actually figure out if 
> 1) the LSP is sending the wrong information; or
> 2) Kate's handling of the LSP information is wrong; or
> 3) The actual *theme* is overwriting something.

What I mean is that the colors you will see depend on the theme you are using. If a theme is bad, you will not see good semantic highlighting colors. And *some* themes work better, because more effort was put into those themes to make them look better.

> I am aware that Kate's syntax highlighting is a lot older than the LSP code, and that it might be difficult to create 1-to-1 mappings for 
> everything, but with LSP being so common nowadays, wouldn't it make sense to adopt the categories (type, variable...) that LSP uses?

It is not that different, and our themes already support the basic semantic highlighting spec pretty well. Some things are missing (for e.g parameter colors) that we can support.

So, if a theme doesn't look good, what you can do is modify the colors and see the effect. But it will be a bit annoying to do this with LSP semantic highlighting because you will need to restart Kate to see the newly applied colors for semantic highlighting.

If you want to see which themes colors get mapped to what LSP information, check the file semantic_tokens_legend.cpp in the Kate repo.