https://bugs.kde.org/show_bug.cgi?id=446121
Waqar Ahmed <waqar....@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |waqar....@gmail.com
--- Comment #1 from Waqar Ahmed <waqar....@gmail.com> ---
> 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)
--
You are receiving this mail because:
You are watching all bug changes.
