> I'm not sure highlighting types based on the caller method and position
> is a good idea. I think that's backward, logically. If one puts a
> non-type value in such argument, and we would highlight it as a type --
> that seems like the wrong message.
These two functions expect a type (or tuple of types) as the second
argument. To address your concerns about highlighting as a type a
non-type variable, I added regexp python--treesit-type-regex. This regex
matches if text is either built-in type or text starts with capital
letter. I extracted built-in types from the python--treesit-builtins
into its own variable python--treesit-builtin-types.
python--treesit-builtins is now constructing by appending
python--treesit-builtin-types and other built-ins. I hope it is ok.
> One of the complaints is that "User" is not highlighted as a type when
> used in other, non-built-in methods, which like a reasonable question to
> me. Yes, Python is dynamic, but using CamelCase for types is a fairly
> regular convention, so highlighting such identifiers as types can work.
It is good idea, to highlight some variables as types. But I think it
should be done on the 4th level. One could split the variable feature
into multiple features: variable-type, variable-argument, variable-use,
etc. So for variable-type feature we can use python--treesit-type-regex
and highlight matched identifiers with type face. For now I wanted to
properly highlight types in places where they expected to be.