From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode Date: Wed, 13 Dec 2023 21:54:16 -0800 Message-ID: References: <8734xdni6y.fsf@yandex.ru> <831qcwycbj.fsf@gnu.org> <83v8a3qh6m.fsf@gnu.org> <834jhadvkt.fsf@gnu.org> <7aee7e42-c07d-9131-18a9-4806f07d4267@gutov.dev> <83a5qw7izt.fsf@gnu.org> <172531702081590@mail.yandex.ru> <212931702208489@mail.yandex.ru> <0c6e2e14-b494-a8cb-3893-ffb39577baf9@gutov.dev> <7b17c99d-6e4b-43b3-af93-993901a3a4ea@gmail.com> <95071702343720@mail.yandex.ru> <78ffdcf3-e322-49ea-a0d5-d0485ade9e73@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29991"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Denis Zubarev , "67061@debbugs.gnu.org" <67061@debbugs.gnu.org> To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 14 06:55:17 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rDegm-0007WN-9o for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 Dec 2023 06:55:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rDegJ-0003KE-Im; Thu, 14 Dec 2023 00:54:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rDegI-0003Jk-Ig for bug-gnu-emacs@gnu.org; Thu, 14 Dec 2023 00:54:46 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rDegI-0003RJ-AZ for bug-gnu-emacs@gnu.org; Thu, 14 Dec 2023 00:54:46 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rDegY-0007kC-C4 for bug-gnu-emacs@gnu.org; Thu, 14 Dec 2023 00:55:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Dec 2023 05:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67061 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 67061-submit@debbugs.gnu.org id=B67061.170253329829753 (code B ref 67061); Thu, 14 Dec 2023 05:55:02 +0000 Original-Received: (at 67061) by debbugs.gnu.org; 14 Dec 2023 05:54:58 +0000 Original-Received: from localhost ([127.0.0.1]:60018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rDegU-0007jp-1H for submit@debbugs.gnu.org; Thu, 14 Dec 2023 00:54:58 -0500 Original-Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]:61493) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rDegN-0007jX-Gb for 67061@debbugs.gnu.org; Thu, 14 Dec 2023 00:54:56 -0500 Original-Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-286f22c52c7so5546712a91.2 for <67061@debbugs.gnu.org>; Wed, 13 Dec 2023 21:54:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702533269; x=1703138069; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=o+PzLQmH/smHIh1Kwd6wvnNYyhNrTBPQFcp+HojyzkQ=; b=c8iiJv+ofo6k6zHXK9VljNXm4m3Qn11WV4mNHdBc/FlKyxXcmMjQcA3yuKOB/CrjjK XmCJP5UWfMh3sB8SGd8QNoEJFzqYAiMbRJLU3WqN6GL4VbPQz4svbjt3jK8dCi5U+QdV 1+jE5l1idEQZUEiYpSHM4ctoBSm5jJfK/t29I5s2jUmg/1aDe94EkDCXeUenI/b0mx0Q 8TeaECNQJV/JoEbjFud/exMEXQdW31v22STrwn0zrDKO9HmalI+y/tP6UwJRtJFLh7Vr 8pE+IGX5CrDzn0lTzE/3HcdGg/CLaofk0lu1/Gae4E1da70tKUAEwoxpd1Iu1Rke6Mvk GWsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702533269; x=1703138069; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=o+PzLQmH/smHIh1Kwd6wvnNYyhNrTBPQFcp+HojyzkQ=; b=ZGIragaPwrL0iwGOQjUsnJD4jpNOVkqW2kbaOpORoi0F3I6Cwe4fE9WSt3iyhYnGCE lcOdYb8miE7R9mGtGGJxRa4TBw6afZYD71dIT9pjHE2mRBEmQNgh/k/7AyVCh0wXn4b+ i8OTPwuw3Eu/DyD/ZevUVrViNfiykyziL4TMejjvMcF/nWHRVa+R+tC1shaQ6Akp9S5j 2P8rkIvhRiYTYBKI1rp9Fe21aFg3yf0+fzB1U8g4lps3WF5OV8+sXqCUXBnGaoJgaByO IoU36jgZgXxK33IPdO+EXhFE5ENURLKUlv0gY6liBj6jOFtxoZdeEtZLtlpvRP8rg79o hW+g== X-Gm-Message-State: AOJu0Yyxv+OrFO2Io0vvnroUnvmr7uL/AsHpLQf4u8i7f2RzfeYHnOnE hVldopKuBTkaSpPQCSDINHY= X-Google-Smtp-Source: AGHT+IHjfbWy+g+AOIdb4rRsJGeihYhs1kOD7BXj0TvMNHNdaEPaML2wVHV0k2r68tcvPAvMeoTl/w== X-Received: by 2002:a17:902:6506:b0:1d3:4ff0:f81c with SMTP id b6-20020a170902650600b001d34ff0f81cmr1333548plk.7.1702533268811; Wed, 13 Dec 2023 21:54:28 -0800 (PST) Original-Received: from smtpclient.apple (172-117-161-177.res.spectrum.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id iy20-20020a170903131400b001d33f3d8768sm3922965plb.149.2023.12.13.21.54.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2023 21:54:27 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.3731.700.6) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:276172 Archived-At: > On Dec 13, 2023, at 10:28 AM, Dmitry Gutov wrote: >=20 > On 13/12/2023 05:49, Yuan Fu wrote: >=20 >>> 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. >=20 > 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=E2=80=99m 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=E2=80=99s not added to the definition feature, because, = again, definition is at level 1 and I don=E2=80=99t want to keep level 1 = minimal. Maybe we can use local-definition, or something similar, to signify that = this feature highlights scoped definitions. >=20 >>> in c-ts-mode highlighting for 'int i =3D 4' is split between = 'definition' and 'assignment' (the latter seemingly redundant);=20 >> Should've been in assignment IMO. I probably overlooked it. >=20 > The current state is that the query in 'definition' can highlight both = 'int i;' and 'int i =3D 4;'. The query in 'assignment' in c-ts-mode only = highlights 'int i =3D 4;'. >=20 > 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=E2=80=A6 hmm=E2=80=A6 This one is hard to decide... >=20 >>> 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. >=20 > 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? >>>=20 >>> 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. >>>=20 >>> 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. >=20 > 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=E2=80=99m ok with either. And I=E2=80=99ll leave it to you guys to = decide, like I did other faces we added in Emacs 29 ;-) Yuan=