I'm looking for somebody who have seen KSyntaxHighlighter code few times, i.e. has idea what is it's interface design and who knows somewhat Kate and how these things are glued together (I didn't check the actual source yet and I'm non-KDE developer (assembly, C++, ...)).

My idea:
- to add API to KSyntaxHighlighter for feeding it keyword lists under some name (like "Asm-m" for macros found by CTags)
- to have a way to specify rules using these names (or actual <keyword> seems sufficient, like "<keyword attribute="Macro Identifier" context="#stay" String="Asm-m"/>")
- Kate would notice (already must know, I guess, as auto-completion uses parsed tags) when CTags does update the tags database, and it would refresh KSyntaxHighlighter with fresh lists (maybe configurable, i.e. sending down only list of certain language-kinds, like sending "Asm-m" for macros in assembly, but labels list ... although for my particular purpose sending all would be ok and performance-wise bearable), and refresh rendered text with refreshed highlighting.

Question:
- does it sounds technically feasible, inter-connecting these parts a bit more through new API on syntax highlighter side, like is it still in alignment with current API design and original vision?
(I mean as non-KDE developer I can imagine how to implement it in tools/frameworks I'm working with daily, and I have hard time to imagine why KDE framework would have major problem to implement it, but I can also easily imagine such API would make major departure from current feel of the API of syntax module, which seems at this moment reasonably clean and trivial and self-contained)

Motivation for this suggestion:
I made syntax highlight rules for Z80 assembly and it works reasonably well.
But as the "constants" (labels defined by "equ"), "macros" (labels defined by "macro") and ordinary labels, are all indistinguishable from each other when used (they are all "identifiers" and there's no distinct feature to separate them) - the final result is colouring either instructions like keywords or identifiers as identifiers (two colours used almost for everything), lacking this subtlety of how the identifier was defined and what it represents. And these are often defined even in different file than their actual usage happens, so even marking identifier somehow upon definition inside syntax rules will not help, the definitions are "included" and then just used as "identifier").

But that extra info is available from CTags, which *did* parse the sources and produced database of tags, including their type ("kinds" in CTags docs), and Kate has this database available (with CTags Pluging enabled), as it is using them for auto-completion, so "all" is needed is "just" to allow the Kate to send such info to syntax highlighter, and having way to use such info in syntax highlight rules.


So, somebody with some understanding of Kate inner-working (plugins API, etc) - how complex such thing would be and does it feel like something in line with current codebase design, or against it?