Yes, but is that classification useful enough to justify the duplication in the
font-lock rules' definitions?
FWIW, I "broke" python-ts-mode in 8503b370be1, according to this definition.
Sorry?
But what do we get by this particular classification?
The user will be able to disable 'definitions' and still have all function
definitions highlighted? But not, say, variable definitions?
That doesn't strike me as particularly more useful than e.g. disabling
'definitions' and having all function references highlighted (but not
definitions). Which we would make possible by limiting 'function' to
non-definitions.
Right now you can choose to highlight:
1. Only definition identifiers, be it function, variable, class, etc
2. All function identifiers
3. All variable identifiers
There could be better features, but the existing ones still have their merits. If
you want a feature that highlights only funcalls, maybe we can add them, if there
are enough time & interest.
Okay, I also have a different, somewhat related question.
Certain languages have a special syntax for "variables".
Ruby has @instance_variable and $global_variable -- the @ and $ are used both
during assignment and for later reference.
Perl has $var and @array_var.
PHP has $local_var.
Up until now we've highlighted those with font-lock-variable-name-face. Except
for @array_var in Perl, which has separate derived face. Either way, we did
highlight them.
What category should we use for them in ts-based modes? If it's 'variable',
then won't be highlighted by default.
If 'variable' matchers in other existing ts modes didn't include all
identifiers everywhere, we could put 'variable' into level 3.
Or we could add a separate category for all those, I guess.
If a major mode thinks highlighting all variables is the best default behavior,
it can support the variable feature and put it at level 3. The standard list is
just a guideline.