On 13/12/2023 05:49, Yuan Fu wrote:

 Python doesn't have special keywords for variable declarations (unlike
 'let' in JavaScript or typed declaration in C), so the first time a
 variable is introduced serves as its declaration. For assignments, we
 can't easily determine which is the first time for a given scope, but
 examples like 'for var in ...' or 'except ZeroDivisionError as e:' or
 '[... for var in ...]' are all unambiguously variable definitions.

 
 Sure, I don't really care too much about which feature should a rule be
 in; what I do care about is to keep first and second fontification level
 relatively quite and minimal, and keep level 3 reasonably conservative.
 And people that want a lot of highlight can turn on level 4.

I don't mind if assignments in python-ts-mode go to level 3, that's what
ruby-ts-mode does anyway. But '[... for var in ...]' really should use
variable-name-face and it should be in the default config (level 3 at
most). I think the 'definition' feature is good for it (going by the
name, since it's an implicit variable declaration), but it could be
split off into a separate feature too.

 in c-ts-mode highlighting for 'int i = 4' is split between
 'definition' and 'assignment' (the latter seemingly redundant);

 
 Should've been in assignment IMO. I probably overlooked it.

The current state is that the query in 'definition' can highlight both
'int i;' and 'int i = 4;'. The query in 'assignment' in c-ts-mode only
highlights 'int i = 4;'.

If you just keep the latter query, 'int i;' would stay unfontified. If
you move the corresponding query from 'definition' to 'assignment', it
would start matching non-assignment declarations too. Might seem odd.

 typescript-ts-mode and rust-ts-mode also follow the principle, more or
 less.

 
 Well, the only ts-mode that I actually wrote is python-ts-mode. For
 other major modes, I can only suggest. Even for python-ts-mode, I don't
 want to exert my personal opinion onto it too much, except for keeping
 font-lock level 1 and 2 quiet.

For my part, I mostly care about keeping the level 3 feature-rich
enough, but precise at the same time. And without frivolous highlights
(only a little more fruit-salady than the pre-treesit modes).

 My thoughts about parameters. I started to extend rules for them
 since they are very limited now.
 But I'm not sure what face to use for them.
 I would like to not use the same face as for assignments, because
 I'd want to highlight them differently.
 It seems that there is no appropriate face in font-lock.el, so I
 ended up creating my own face in my config.
 Does it make sense to add new face for parameters in font-lock.el?
 Or it is too small feature for its own face?
 I also apply this face for keyword argument in function calls.

 To be honest, I don't have any good ideas. Perhaps we can add a
 parameter face that inherits from variable name face by default,
 Dmitry, WDYT?

 As per above, parameters don't seem too different from any other
 variable declarations from my POV. They are similarly useful, so I'd
 highlight them the same way.

 Do we want to have a common face which would inherit from
 font-lock-variable-name-face and would be used solely for
 function/methods parameters and nothing else? I don't object, but I
 don't quite see the point either.

 
 I agree.

Then I suppose we should clarify whether Denis wants a face that only
matches function parameters, or implicit variable declarations as well.
Or maybe instead a face that is only used for assignments (only first
assignments?) -- which would separate them from the two semantic units
above.