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 02:44:30 +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: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15031"; 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 01:45:20 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 1rDDNH-0003fJ-6b for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Dec 2023 01:45:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rDDMm-00068x-Lz; Tue, 12 Dec 2023 19:44:48 -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 1rDDMl-00068M-2b for bug-gnu-emacs@gnu.org; Tue, 12 Dec 2023 19:44: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 1rDDMk-0002KR-Nl for bug-gnu-emacs@gnu.org; Tue, 12 Dec 2023 19:44:46 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rDDN0-00074U-29 for bug-gnu-emacs@gnu.org; Tue, 12 Dec 2023 19:45: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 00:45: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.170242830127157 (code B ref 67061); Wed, 13 Dec 2023 00:45:02 +0000 Original-Received: (at 67061) by debbugs.gnu.org; 13 Dec 2023 00:45:01 +0000 Original-Received: from localhost ([127.0.0.1]:57956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rDDMy-00073v-D7 for submit@debbugs.gnu.org; Tue, 12 Dec 2023 19:45:00 -0500 Original-Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:46607) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rDDMw-00073h-HS for 67061@debbugs.gnu.org; Tue, 12 Dec 2023 19:44:59 -0500 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 8A6FE3200B03; Tue, 12 Dec 2023 19:44:36 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 12 Dec 2023 19:44:36 -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=1702428276; x=1702514676; bh=UISs3FANMAyg/nRQSxHTl/32uX16b6U3HZFaXhdDkSA=; b= W86RxARu5jCe5b5/VK9OAuH8ceKQr4FTf0tiRv2BE/+1A46LibiT3s4SChgbv4LH 8N7NFSpCKMTF5xGZP397RIWDSmib7THPYkN/NwGVSlZQP3XoJJvVMGL4y0c+4cWs FM8JipHN8HzE6x/h0QEa7MEs0tMiHaVeXGkAPtB/lkHek2zUtpym+H/DqeTtPny0 j5i67t7A4rEXa06xAejE4xMr8hXGoHJ8qHAx+7CmUoy+TEIXMPBe1zY5hIQMVoDG tLGcVZiu0dnP9OKgAsMXko+7Rz/PkhK3pS42rHCgM+zRnz2dn4//bAHCmyf0L7Qz KXJRF/lt8+g+HeA1IA39PA== 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=1702428276; x= 1702514676; bh=UISs3FANMAyg/nRQSxHTl/32uX16b6U3HZFaXhdDkSA=; b=X PX+lWPnVn25ePBfx7YWW9HDQobBUB0JDx5REyQ5586iVf4vRe2EQaOAMSn5x0GwK kMw4X/AhoxbFFRjpBg+xVB3r17N3krZ8pPX4WWOwg1OugsUaJy05r0+N5SQtgBKN kSFPp3v7ZqR6M6kin3oSPCONGm660xlalO2NXd0MqfPkX48cALsOKK5USryzpfv4 hRbKpOlSSSPt3e8o67tczv17OfKF7w6dQrd6Qql5B7ixnAy1wL5fHbGdHZvdHE5u TUjKkCEJz081MS2mvoleLPL+/SNHcYa5yTWP/gr2ipdOuwIfRTbWrJxjxGQQ0UeN MIYIvi92C75KWit3d2mHA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudelhedgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Dec 2023 19:44:34 -0500 (EST) Content-Language: en-US In-Reply-To: <78ffdcf3-e322-49ea-a0d5-d0485ade9e73@gmail.com> 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:276102 Archived-At: 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.