unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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, 13 Dec 2023 21:54:16 -0800	[thread overview]
Message-ID: <E437457A-BC8F-418C-BB60-5CFA042E60FF@gmail.com> (raw)
In-Reply-To: <be0daff8-20aa-ea73-2935-fa7e9f04e201@gutov.dev>



> On Dec 13, 2023, at 10:28 AM, Dmitry Gutov <dmitry@gutov.dev> wrote:
> 
> 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.

Assignment is in level 3 for python-ts-mode.

> But '[... for var in ...]' really should use variable-name-face and it should be in the default config (level 3 at most).

I’m fine with that.

> 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.

As long as it’s not added to the definition feature, because, again, definition is at level 1 and I don’t want to keep level 1 minimal.

Maybe we can use local-definition, or something similar, to signify that this feature highlights scoped definitions.

> 
>>> 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.

Right… hmm… This one is hard to decide...

> 
>>> 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).

Sounds good to me :-)

>>>>> 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.

I’m ok with either. And I’ll leave it to you guys to decide, like I did other faces we added in Emacs 29 ;-)

Yuan




  reply	other threads:[~2023-12-14  5:54 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 [this message]
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

  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=E437457A-BC8F-418C-BB60-5CFA042E60FF@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).