From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jacob Faibussowitsch Newsgroups: gmane.emacs.bugs Subject: bug#61655: [Tree sitter] [Feature Request] font-lock function calls, definitions, separately Date: Wed, 22 Feb 2023 13:07:32 -0500 Message-ID: <7B23CCBC-9B9F-4E1A-AE5F-0DBDD2FE2C26@gmail.com> References: <8DA1B548-B8D2-4EC1-B9F8-F7654003AC89@gmail.com> <56C0998E-3053-49F3-BAE3-46D6432B16F5@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) 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="7274"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Randy Taylor , Yuan Fu , 61655@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 22 19:08:29 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 1pUtXZ-0001jq-Py for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 22 Feb 2023 19:08:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pUtX9-0003dX-OV; Wed, 22 Feb 2023 13:08:03 -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 1pUtX8-0003bw-ES for bug-gnu-emacs@gnu.org; Wed, 22 Feb 2023 13:08:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pUtX8-00030t-6O for bug-gnu-emacs@gnu.org; Wed, 22 Feb 2023 13:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pUtX7-00027C-JT for bug-gnu-emacs@gnu.org; Wed, 22 Feb 2023 13:08:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jacob Faibussowitsch Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Feb 2023 18:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61655 X-GNU-PR-Package: emacs Original-Received: via spool by 61655-submit@debbugs.gnu.org id=B61655.16770892658102 (code B ref 61655); Wed, 22 Feb 2023 18:08:01 +0000 Original-Received: (at 61655) by debbugs.gnu.org; 22 Feb 2023 18:07:45 +0000 Original-Received: from localhost ([127.0.0.1]:60300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUtWq-00026a-Sm for submit@debbugs.gnu.org; Wed, 22 Feb 2023 13:07:45 -0500 Original-Received: from mail-qt1-f172.google.com ([209.85.160.172]:34485) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUtWl-00026F-WD for 61655@debbugs.gnu.org; Wed, 22 Feb 2023 13:07:43 -0500 Original-Received: by mail-qt1-f172.google.com with SMTP id b6so2244619qtb.1 for <61655@debbugs.gnu.org>; Wed, 22 Feb 2023 10:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=aXw+7ZfR/B9wHVczz/ZrFfMc+zGj7gfZ1+3vQA6Fthg=; b=Rp7hhHEnMSIfvhCHE0yYovSKEgl+3LZq252CtwJ7BJkSF+obb9w1Y7FI/hG8xZPLJg CBUbrBPJmfJfimjPD2CRbC/7rsOr3sU3189RhjmuUizjS9aRUJm9dFCYH5La4UCpiH5y Mw+PzZDomuTH9oOZ9kucDwYR3yj90leW7MfSXJaYEVnh4IniTqguDihM7aJyDBwjVPwI w/DdlxidP0utLyjUxrlHMUdL2/NWnRvz1gdIRa/mRURzxtnHd6VX7IXbR9O9AHx4kRRj 4OpnOEFfoaKoqUBTFZ2SPVQrJu6bT71Wu02osCdS9gaHEs+Gd2NyMIUFBAdq6w1bWbsf 6Jtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=aXw+7ZfR/B9wHVczz/ZrFfMc+zGj7gfZ1+3vQA6Fthg=; b=pmDbOhrQoHU8KZzLEeYUXwrVELqFEpCRoBU3Di7g5bvdaSDnEg2ivneGpd2ul+UKEA 6b07x5PUGjqhYNgXDS+WiCbt99niij43PXV/QY+Qwsp1ex3OEfxSbr92UFkGZb+e5YVS T496CY2NXng7l4nsyjBZGql2QclvD/3QZB2d81va3V0IouuoYANaGXJapPQlMSI9N8vu UvilT3LeQIGaXSwQh8oKDYC7Nbd1NBrWrRbr6YVPYmutGFVLeUKBN2uldzmpov4tIXin lfoER4PnN5t/Sw7Qh5VL7FvbO/qMBGvoP8WMOfuq5OaFBDDm5P6azTLxNVzxTKievFUB /EfQ== X-Gm-Message-State: AO0yUKXcw8Txq8Sqwk3/yknRbWBvxMr0X39OQAaX+j61wat8jEWjnCIt 3kCuyiH1oh5xJnSstk1Gi9M= X-Google-Smtp-Source: AK7set8SgZYJmnrBox3NFi8tIXLp6Wb+wURZNfsamctESVm236zH0au8/a4YhmeNCnHMdGTVXl21uw== X-Received: by 2002:a05:622a:1188:b0:3b6:2c58:cbcf with SMTP id m8-20020a05622a118800b003b62c58cbcfmr16290033qtk.4.1677089254216; Wed, 22 Feb 2023 10:07:34 -0800 (PST) Original-Received: from smtpclient.apple (pool-108-21-63-133.nycmny.fios.verizon.net. [108.21.63.133]) by smtp.gmail.com with ESMTPSA id b14-20020ac801ce000000b003ba11bfe4fcsm2094200qtg.28.2023.02.22.10.07.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2023 10:07:33 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.3696.120.41.1.2) 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:256389 Archived-At: > What's a "member function"? Is it like a method? Yeah, I suppose method is the more general term for it. > If people want this distinction, we can add such face. But I'm curious = whether some other editors use different colors for these cases. I personally do not; I brought it up because it was functionality that = the 3rd party package had over stock. I think a good representative list = is the one vscode offers: = https://code.visualstudio.com/api/language-extensions/semantic-highlight-g= uide#standard-token-types-and-modifiers > I'm also wondering what face we're supposed to use for "receiver-less" = method calls, such as calls to the methods defined in the same class, in = e.g. Ruby and Java. Or C++/C#. They don't use =E2=80=98this=E2=80=99. I don=E2=80=99t think emacs should worry about differentiating these = cases. Highlight those tokens as tree-sitter sees them; regular function = calls (i.e. `font-lock-function-call-face`). It=E2=80=99s a problem you = cannot accurately solve without playing the compiler =E2=80=94 with all = of the implementation and not to mention performance baggage that comes = with it. > I also wonder whether we'll need to separate faces for properties: = definitions vs. uses. That one we could use to do early, to keep the = names uniform, e.g. we'd have: This is something (also 3rd party package) lsp-mode supports through = their semantic highlighting. They further distinguish between read and = writes to variables. But again, they are able to do so because they hook = directly into compilers. Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) > On Feb 21, 2023, at 18:24, Dmitry Gutov wrote: >=20 > On 21/02/2023 17:31, Jacob Faibussowitsch wrote: > > but maybe a better default is to leave these faces totally blank and > > just purely `:inherit` from `font-lock-function-name-face` >=20 > I believe so. >=20 >> +(defface font-lock-function-call-face >> + '((t :inherit font-lock-function-name-face :foreground = "royalblue1")) >> + "Font Lock mode face used to highlight function calls." >> + :group 'font-lock-faces) >=20 > This one I was thinking of as well. >=20 >> +(defface font-lock-member-function-call-face >> + '((t :inherit font-lock-function-name-face :foreground = "brightred")) >> + "Font Lock mode face used to highlight member function calls." >> + :group 'font-lock-faces) >=20 > What's a "member function"? Is it like a method? If people want this = distinction, we can add such face. But I'm curious whether some other = editors use different colors for these cases. >=20 > I'm also wondering what face we're supposed to use for "receiver-less" = method calls, such as calls to the methods defined in the same class, in = e.g. Ruby and Java. Or C++/C#. They don't use 'this'. >=20 > I think more importantly, we need a new face for variables. >=20 > font-lock-variable-ref-face ? >=20 > I also wonder whether we'll need to separate faces for properties: = definitions vs. uses. That one we could use to do early, to keep the = names uniform, e.g. we'd have: >=20 > font-lock-function-name-face > font-lock-function-call-face > font-lock-variable-name-face > font-lock-variable-ref-face > font-lock-property-name-face > font-lock-property-ref-face