What would be examples for TKText? Does it differ from string?
I have not decided yet about the scope of the highlighters. I consider that the HL should be just a lexer, but it this way, it wouldn't have to analyze KEYWORDS, that IMHO are syntactic elements. So in some cases we need to extend the scope of the HL.
In my highlighter's documentation, I have moreless, this definition:
Constants, Variables, Directives, Functions could be consider like a sub-category of Identifiers, in most of the cases, but in some syntaxs they could have some lexical special definitions, like the variables in PHP.
This attempt to structure tokens, on a global (across all Highlighter) level, is adding to my dislike of the initial idea.
You can define that for a selected set of HL. But any HL is free to break this rules.
By definition, HL is not even restrained to be a lexer. IT could be anything. Of course a higher level of complexity would bring new problems (speed). But there may be a usecase where this does not matter (e.g. it is known that the data will always be small).
The point is that those ID should not limit the future of HL. This is why I already pointed out that a warning will go along with them, that the concept of such ID may be broken in future.
As in the example where a HL dynamically generates new Attributes (SynPasSyn already does). Such dynamically generated attributes are only known while parsing the tokens. they can not be returned by getDefaultAttr.
HL may also be nested (asm HL as part of the pas HL) This will lead to more than one default for the same token kind.
With asm, in pas, you may define the default as taken from pas.
But with the SynMulti, there is an outer HL (that may have almost none attribs of its own), and then there are many HL all nested at the same Level. What then?
---
So in conclusion: Those ID, will be an extension, that in a limited number of cases may be used succesful, but with no guarantee of support in future versions (other than in HL written by the person themself)
For that reason, I want to keep any future work resulting out of this at a minimum.
So if it must be
* SYN_ATTR_TEXT (not my favourite)
* SYN_ATTR_VARIABLE
* SYN_ATTR_DIRECTIVE (used by Pascal and C++)
* SYN_ATTR_ASM (used by Pascal and C++)
can be added.
SYN_ATTR_FUNCTION would be a bad name, they a like a 2nd group of keywords., but next is a HL, wit 3 group of keywords. Or 4 group of numbers.
Pascal has 3 sort of comments(but they shore one attribute / until now, but what if pasdoc will be recognized?)
Pascal has 2 directives (fpc {$...} and ide {%...}
the 2nd has a dynamically created attribute.
---
Absolutely no promise of maintenance.
Still not sure how this will be of use....