bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode

[Dmitry Gutov <dmitry@gutov.dev>]

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.