From: Dmitry Gutov <dmitry@gutov.dev>
To: Yuan Fu <casouri@gmail.com>, Denis Zubarev <dvzubarev@yandex.ru>,
Eli Zaretskii <eliz@gnu.org>
Cc: "67061@debbugs.gnu.org" <67061@debbugs.gnu.org>
Subject: bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode
Date: Wed, 13 Dec 2023 02:44:30 +0200 [thread overview]
Message-ID: <b57c896a-a6cb-9a08-c254-aae25cbf5314@gutov.dev> (raw)
In-Reply-To: <78ffdcf3-e322-49ea-a0d5-d0485ade9e73@gmail.com>
On 12/12/2023 10:24, Yuan Fu wrote:
>> > I think "for var in range(3)" should be part of the "definition"
>> feature
>> because a variable is defined there. Alongside parameters.
>> I added it to definitions.
>
> Again, if we think of fontification levels, the definition feature is
> about fontifying the function names of definitions, and it's at a low
> level (level 1). Non-essential fontification like "var" shouldn't be
> activated at that level. So I suggest to put it in the variable feature,
> along with many other non-essential fontifications. (Variable feature is
> placed at level 4.)
I disagree: 'var' in this example is not much different from a function
parameter. It's a definite place where a variable's name introduced in
the current scope.
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.
So I think that:
a) All variable definitions (functions parameters or not) should use
font-lock-variable-name-face -- to make it easier to find where a given
symbol is introduced.
b) No font-lock-variable-name-face highlights should be put into the
'variable' feature, which is disabled by default. All of the examples
above should either go into 'definition', or if somebody does like that
approach, into some new 'variable-declaration' feature (enabled by
default). And maybe some into 'assignment', which is on feature level 3.
c) The 'variable' feature should, at this point, only contain the
relatively useless highlights, since we don't track variable lifetimes
yet. That's why it's disabled by default.
The current situation across ts modes is that js-ts-mode has variable
declarations in the 'definition' feature (and not by my hand, FWIW);
ruby-ts-mode has a separate 'parameter-definition' feature that
encompasses both parameters and other variables; in c-ts-mode
highlighting for 'int i = 4' is split between 'definition' and
'assignment' (the latter seemingly redundant); typescript-ts-mode and
rust-ts-mode also follow the principle, more or less.
>> 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.
next prev parent reply other threads:[~2023-12-13 0:44 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-11 2:21 bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode Denis Zubarev
2023-11-11 7:32 ` Eli Zaretskii
2023-11-11 10:52 ` Denis Zubarev
2023-11-11 11:00 ` Eli Zaretskii
2023-11-11 12:09 ` Denis Zubarev
2023-11-26 2:12 ` Dmitry Gutov
2023-11-15 13:28 ` Eli Zaretskii
2023-11-25 9:35 ` Eli Zaretskii
2023-11-26 2:17 ` Dmitry Gutov
2023-11-29 14:05 ` Eli Zaretskii
2023-12-09 0:39 ` Denis Zubarev
2023-12-09 7:32 ` Eli Zaretskii
2023-12-10 10:16 ` Yuan Fu
2023-12-09 18:18 ` Dmitry Gutov
2023-12-10 12:04 ` Denis Zubarev
2023-12-11 0:00 ` Dmitry Gutov
2023-12-11 7:10 ` Yuan Fu
2023-12-11 12:02 ` Dmitry Gutov
2023-12-12 1:18 ` Denis Zubarev
2023-12-12 8:24 ` Yuan Fu
2023-12-13 0:44 ` Dmitry Gutov [this message]
2023-12-13 3:49 ` Yuan Fu
2023-12-13 18:28 ` Dmitry Gutov
2023-12-14 5:54 ` Yuan Fu
2023-12-14 11:51 ` Dmitry Gutov
2023-12-17 1:07 ` Yuan Fu
2023-12-17 21:36 ` Dmitry Gutov
2023-12-23 21:46 ` Denis Zubarev
2023-12-16 13:03 ` Eli Zaretskii
2023-12-17 1:56 ` Denis Zubarev
2023-12-17 23:38 ` Dmitry Gutov
2023-12-13 11:52 ` Eli Zaretskii
2023-12-17 0:26 ` Denis Zubarev
2023-12-17 1:10 ` Yuan Fu
2023-12-17 2:07 ` Denis Zubarev
2023-12-23 9:42 ` Eli Zaretskii
2023-12-30 10:53 ` Denis Zubarev
2023-12-30 11:19 ` Eli Zaretskii
2023-12-18 0:25 ` Dmitry Gutov
2023-12-19 0:14 ` Denis Zubarev
2023-12-20 23:34 ` Dmitry Gutov
2023-12-21 7:04 ` Yuan Fu
2023-12-23 21:45 ` Denis Zubarev
2024-01-01 17:42 ` Dmitry Gutov
2024-01-09 20:03 ` Eli Zaretskii
2024-01-20 9:08 ` Eli Zaretskii
2024-01-27 9:49 ` Eli Zaretskii
2024-01-27 10:47 ` Denis Zubarev
2024-01-27 11:30 ` Eli Zaretskii
2023-12-13 21:16 ` Stefan Kangas
2023-12-14 1:31 ` Dmitry Gutov
2023-12-14 22:49 ` Stefan Kangas
2023-12-15 7:14 ` Yuan Fu
2023-12-11 6:53 ` Yuan Fu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b57c896a-a6cb-9a08-c254-aae25cbf5314@gutov.dev \
--to=dmitry@gutov.dev \
--cc=67061@debbugs.gnu.org \
--cc=casouri@gmail.com \
--cc=dvzubarev@yandex.ru \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.