From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode Date: Wed, 13 Dec 2023 20:28:39 +0200 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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31038"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: "67061@debbugs.gnu.org" <67061@debbugs.gnu.org> To: Yuan Fu , Denis Zubarev , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 13 19:30:09 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 1rDTzk-0007tM-CI for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Dec 2023 19:30:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rDTzR-0005t0-Tw; Wed, 13 Dec 2023 13:29:49 -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 1rDTzO-0005qg-QX for bug-gnu-emacs@gnu.org; Wed, 13 Dec 2023 13:29:47 -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 1rDTzO-0004b2-Fl for bug-gnu-emacs@gnu.org; Wed, 13 Dec 2023 13:29:46 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rDTze-0006U4-6v for bug-gnu-emacs@gnu.org; Wed, 13 Dec 2023 13:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Dec 2023 18:30: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.170249215224843 (code B ref 67061); Wed, 13 Dec 2023 18:30:02 +0000 Original-Received: (at 67061) by debbugs.gnu.org; 13 Dec 2023 18:29:12 +0000 Original-Received: from localhost ([127.0.0.1]:59662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rDTyp-0006Sd-Ez for submit@debbugs.gnu.org; Wed, 13 Dec 2023 13:29:11 -0500 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:56101) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rDTyj-0006S4-LR for 67061@debbugs.gnu.org; Wed, 13 Dec 2023 13:29:09 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4692C5C040F; Wed, 13 Dec 2023 13:28:44 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 13 Dec 2023 13:28:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1702492124; x=1702578524; bh=WcMQXgzYiDZ2fUhRrmwahHgoXszgoDKmHaJF+JWwFCw=; b= ycmuNJ92LuZBCV9e9t83ZWuVqMiLPQdwnhW1DTugFFDwWu36lwDaIj/SVk57DWNg RrV6LRAakO+kKrAImd3CZiIFkLzC+b8+rh5Lm8c9vN0flkprBX6e8IkVuB3XcK9S Ya2bLtGXx8Xlxi1Ag0XzAlWnMT/clHL/3NkeHE5RL66VxlUaepldO3M7yxFgnqdg OEAxgeCrzjjnQcCvSKR+OP6WV84Gi1byOlktyrn4sBT2i4thqm+3jEMChq0R+jGY E0RozFz1LN7ixauKj53N26C5rbewmFF8nigXwtT0tgXPiJpxg4EndmcJGvpnS1tA zPPqL6RMiRt1nLglQlpxNA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1702492124; x= 1702578524; bh=WcMQXgzYiDZ2fUhRrmwahHgoXszgoDKmHaJF+JWwFCw=; b=3 OZk2+cAJQoHCqJsx5EXJI2oaVHlJgus5b6wGm30q/SDCwtKAW03y2BjW+4SoPaSa Y1snIvEjeTVcygJ27AZAsXp+O9i6SdIPo540d08++vKqWSB56PnwIdMAOl/l3qNQ OgBwwvYRUbW3KcgPvnZf0w+r2D1jYdNnvOIbsbTA72fCg+dekUE8qt34/xVvde3s YKpgxQl8NgFvpfchoz2FvjjZhjKs1TBz88OJ3n6hmB6z1Vn7GhzzRhRNSkfRqvT+ ItU0TWqTEEN2IR1+m58GagxgZGBFq0+G06hcBsARHKI1RVT6uTky0qaABU+KYR+2 l0fOwKs3TtCFTgtHhJEKw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeljedgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 13 Dec 2023 13:28:42 -0500 (EST) Content-Language: en-US In-Reply-To: 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:276151 Archived-At: 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. But '[... for var in ...]' really should use variable-name-face and it should be in the default config (level 3 at most). 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. >> 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. >> 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). >>>> 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.