[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode
From: |
Dmitry Gutov |
Subject: |
bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode |
Date: |
Mon, 11 Dec 2023 02:00:57 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 |
On 10/12/2023 14:04, Denis Zubarev wrote:
> Arguably, the last 2 lines are "variable references" rather than
definitions
`var := 3` is assignment expressions. It allows variable assignments to
occur inside of larger expressions. For example `if (match :=
pattern.search(data)) is not None:`.
It mostly used to define new variables and act on them if some condition
is met.
Ah, thanks! This feature is newer than my working experience with Python.
My rationale for `var *= 3` was that it is shorthand for `var = var * 3`
and currently the `var` on the left hand side is fontified with
`font-lock-variable-name-face`.
I think ideally, in cases when "var =" is not the first occurrence for
the same var in a given scope, we wouldn't highlight it as "definition"
either.
Speaking of font-lock-variable-use-face, I think it would be most useful
if it helped with noticing typos (meaning, it would only be used for
references to variables that have been defined previously, according to
the rules of the language). But for that we still need to implement the
scope tracking. And before that, well, my personal preference is not to
highlight the references at all, but opinions differ.
I wanted shorthand form to be consistent with the full form.
Your point makes sense too, I don't have strong opinion about this.
Also I'm not sure now about `var[ii] = 1`, since it is actually
accessing the list or dictionary element and
`font-lock-variable-use-face` may suit better here.
Yep. To sum up, I would add highlighting to your examples `for var in
range(3)` and `var := 3` but not others.
Question about new changes.
Should I push them to this patch and provide description of new changes,
or it would be better to wait for review and send them as new patch?
I suggest sending an updated patch for review in this case, but you can
also wait for Yuan's comments first.
Also, please double-check that the tests pass. It might be something in
the way I applied your latest patch, but in the example that you gave
regarding the "type" feature,
def func(v:dict[ list[ tuple[str] ], int | None] | None):
, only the last "None" gets highlighted for me with font-lock-type-face.
There are corresponding test failures too. Again, could be something on
my side, but it would help to verify.
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode, Denis Zubarev, 2023/12/08
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode, Eli Zaretskii, 2023/12/09
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode, Dmitry Gutov, 2023/12/09
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode, Denis Zubarev, 2023/12/10
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode,
Dmitry Gutov <=
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode, Yuan Fu, 2023/12/11
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode, Dmitry Gutov, 2023/12/11
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode, Denis Zubarev, 2023/12/11
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode, Yuan Fu, 2023/12/12
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode, Dmitry Gutov, 2023/12/12
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode, Yuan Fu, 2023/12/12
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode, Dmitry Gutov, 2023/12/13
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode, Yuan Fu, 2023/12/14
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode, Dmitry Gutov, 2023/12/14
- bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode, Yuan Fu, 2023/12/16