From: Yuan Fu <casouri@gmail.com>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: Eli Zaretskii <eliz@gnu.org>, Denis Zubarev <dvzubarev@yandex.ru>,
"67061@debbugs.gnu.org" <67061@debbugs.gnu.org>
Subject: bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode
Date: Wed, 20 Dec 2023 23:04:04 -0800 [thread overview]
Message-ID: <80835E29-BA35-4550-9CAC-DA7AE9F60440@gmail.com> (raw)
In-Reply-To: <16489c3d-bddf-984b-6c98-2a1de9fdb6e8@gutov.dev>
> On Dec 20, 2023, at 3:34 PM, Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 19/12/2023 02:14, Denis Zubarev wrote:
>> > If you recall my earlier complaint that these highlightings didn't work
>> > (and the tests didn't pass), this happened due to an older Python grammar.
>> Thank you for investigating this. It seems this commit introduced
>> changes to type nodes hierarchy (https://github.com/tree-sitter/tree-sitter-python/commit/bcbf41589f4dc38a98bda4ca4c924eb5cae26f7b).
>
> Could be this one, yes.
>
>> > The queries didn't lead to errors either (that's a good thing), but maybe
>> > we'll want to revisit these highlights later to add support for the
>> > older grammar as well.
>> It may lead to unnecessarily complex rules. I don't
>> know is it worth it, since users can easily update grammars.
>
> No problem.
>
>> > 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.
>
> Thank you. I'm actually not sure if we _have to_ check the identifier names in this context (any chance to have a false negative, miss some valid types?), but it probably doesn't hurt either.
>
>> > 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.
>
> I wouldn't mind the level 4 (after all, python-mode is also conservative here and doesn't add such highlighting), but I'd rather not add the special handling for isinstance/issubclass thing for the reasons previously outlined.
>
> Perhaps Yuan will disagree. I'm just here to say that the rest of the patch LGTM.
I wouldn’t mind either, go crazy with level 4 :-) I wouldn’t even mind it in level 3, since they are indeed types. Using a separate feature is a good idea, so people who doesn’t want it can turn it off.
Yuan
next prev parent reply other threads:[~2023-12-21 7:04 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
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 [this message]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=80835E29-BA35-4550-9CAC-DA7AE9F60440@gmail.com \
--to=casouri@gmail.com \
--cc=67061@debbugs.gnu.org \
--cc=dmitry@gutov.dev \
--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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).