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#61655: [Tree sitter] [Feature Request] font-lock function calls, definitions, separately Date: Wed, 22 Feb 2023 12:45:24 -0800 Message-ID: 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 \(3731.400.51.1.1\)) 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="18994"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61655@debbugs.gnu.org, Dmitry Gutov To: Jacob Faibussowitsch Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 22 21:47: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 1pUw1R-0004hN-2d for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 22 Feb 2023 21:47:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pUw06-0006qL-Jq; Wed, 22 Feb 2023 15:46:07 -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 1pUw03-0006px-EI for bug-gnu-emacs@gnu.org; Wed, 22 Feb 2023 15:46:03 -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 1pUw03-0002Ks-5a for bug-gnu-emacs@gnu.org; Wed, 22 Feb 2023 15:46:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pUw02-0006Jk-1S for bug-gnu-emacs@gnu.org; Wed, 22 Feb 2023 15:46: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: Wed, 22 Feb 2023 20:46:02 +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.167709874524259 (code B ref 61655); Wed, 22 Feb 2023 20:46:02 +0000 Original-Received: (at 61655) by debbugs.gnu.org; 22 Feb 2023 20:45:45 +0000 Original-Received: from localhost ([127.0.0.1]:60486 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUvzk-0006JC-Qe for submit@debbugs.gnu.org; Wed, 22 Feb 2023 15:45:45 -0500 Original-Received: from mail-pf1-f181.google.com ([209.85.210.181]:40842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUvzi-0006Iy-CD for 61655@debbugs.gnu.org; Wed, 22 Feb 2023 15:45:43 -0500 Original-Received: by mail-pf1-f181.google.com with SMTP id u20so2422737pfm.7 for <61655@debbugs.gnu.org>; Wed, 22 Feb 2023 12:45:42 -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=M4F4HTgSA1ilIoVUDpKJ+lOlNqvffgi3DcfFHREUrUA=; b=Np7WKKVXcTPmVc7/kqnBwgVoX4rJbClcT2xf6Cu2FHgiu0KfmCLFVo0ThFDDt6WZus jEwIRd/L2OoQwXXsIDuUCxnZ04EzocAyJ5rOahYS4vzDEiHU2DRbbNo4oy5Y2Aqh/EsZ F3M0oTif0Asmy8b1jfL2ZlHPetBWu92haogw8fJlyj4WuJe7IJVG7r0GdfmtT0Xtt4e1 vkOaZuMmlbhAJ5EaNpMu6SMiPodLiOG8H/cJDOK3nzxHxBi5lCuAcZJFMSDN+WGZs13+ 7iX/c5dhbmtx3QawuZR9a+umkgwvnTds3sscpiqAL/zrxKvUrzWiotpxQetBON8OUHpl fLsg== 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=M4F4HTgSA1ilIoVUDpKJ+lOlNqvffgi3DcfFHREUrUA=; b=OSnkQjvOsbdGbU7vaBlbG7TDcfyJEOwXBBeO7BBEbGA66W1mz8C0tDJpoWPf+SFcUU SyZHyrkRUbn9gRgEV3EPX2+A7bU/euVEi0jeGEI8tftDjlcKakuThyemtUIgTPpCXpGY yuGtHTxGxurlExQIizpPa9V1NVpvLVDcBFISkpROJ0uNYudbhjdnHRXHE2GClOS2aFce 26W6kv1WeIGR8K/lkvupwU5E+forrsHkjuu25RBvZj9U/hVXob0i67Bf960ww9I3oiDr 4r4skYQ7FxP+HB+RggSigUhGcPgRfNq3GY88TLmo5zueVRQRW99abQnJOveJGxmRb1pE eMlw== X-Gm-Message-State: AO0yUKWwu4F8dloqOMWFjopJslTA5GKiIvdHnaW0x3RNMYap2naXzi2L 5DODzjJF9gHeo1h07mRA1M8= X-Google-Smtp-Source: AK7set+u4jBTs0hrpkR79hPvRY5bkWYm2mYXtujDUlyd46HPR1xb5KebrNcOrBnwkNi3kfYQZB3Eag== X-Received: by 2002:a05:6a00:1d86:b0:5a8:4ae7:25d5 with SMTP id z6-20020a056a001d8600b005a84ae725d5mr7475395pfw.8.1677098736357; Wed, 22 Feb 2023 12:45:36 -0800 (PST) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id g11-20020aa7818b000000b00588e0d5124asm5453563pfi.160.2023.02.22.12.45.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2023 12:45:35 -0800 (PST) In-Reply-To: <56C0998E-3053-49F3-BAE3-46D6432B16F5@gmail.com> X-Mailer: Apple Mail (2.3731.400.51.1.1) 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:256397 Archived-At: > On Feb 21, 2023, at 7:31 AM, Jacob Faibussowitsch = wrote: >=20 >> but it's a relatively small change, >=20 > Indeed, after playing around with the syntax queries a bit more, all = that is needed to implement this change is the following patch. >=20 > Note for the new faces that I populated the `:foreground` fields to = match the colors for the example I showed in my first email, but maybe a = better default is to leave these faces totally blank and just purely = `:inherit` from `font-lock-function-name-face`. >=20 > diff --git a/lisp/font-lock.el b/lisp/font-lock.el > index 9e944fe188a..d170123c2ca 100644 > --- a/lisp/font-lock.el > +++ b/lisp/font-lock.el > @@ -2026,6 +2026,16 @@ font-lock-function-name-face > "Font Lock mode face used to highlight function names." > :group 'font-lock-faces) >=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) > + > +(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) > + > (defface font-lock-variable-name-face > '((((class grayscale) (background light)) > :foreground "Gray90" :weight bold :slant italic) > diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el > index b7a487687a8..51a65aa6545 100644 > --- a/lisp/progmodes/c-ts-mode.el > +++ b/lisp/progmodes/c-ts-mode.el > @@ -529,8 +529,8 @@ c-ts-mode--font-lock-settings > :feature 'function > '((call_expression > function: > - [(identifier) @font-lock-function-name-face > - (field_expression field: (field_identifier) = @font-lock-function-name-face)])) > + [(identifier) @font-lock-function-call-face > + (field_expression field: (field_identifier) = @font-lock-member-function-call-face)])) >=20 > :language mode > :feature 'variable >=20 > Best regards, >=20 > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) >=20 >> On Feb 21, 2023, at 04:55, Dmitry Gutov wrote: >>=20 >> On 21/02/2023 10:28, Yuan Fu wrote: >>> Hmmm, yeah. The builtin tree-sitter maps syntax queries directly = into >>> faces, where the third-party tree-sitter maps syntax queries to some >>> syntax types, then maps types to faces. So it would be a bit harder = to >>> do fine-grained control like in the builtin tree-sitter, comparing = to >>> the third-party one. >>> I=E2=80=99ve thought of this idea before but didn=E2=80=99t pursue = it further: Right now >>> we allow capture names to be face names and functions, eg >>> (commment) @font-lock-comment-face >>> or >>> (comment) @xxx-moode-fortify-comment >>> Maybe we can add a third type, arbitrary symbols, like >>> (comment) @comment >>> and add a variables treesit-font-lock-mapping which maps symbols to >>> faces or functions: >>> ((comment . font-lock-comment-face)) >>> or >>> ((comment . xxx-mode-fontify-comment)) >>> Then we can easily support differentiating between function call and >>> function definition. >>=20 >> Before we do any of that, don't we need actual different faces to use = for e.g. function definitions and function calls? >>=20 >> Same for variables. >>=20 >> And if we have those, we might not need the indirection, at least not = right away. >>=20 >> I figured we'd add them in Emacs 30, but it's a relatively small = change, if people are interested. >=20 Yeah that=E2=80=99s just an idea, and I don=E2=80=99t have problem = adding faces. But we probably can=E2=80=99t keep adding more and more = specific faces. At one point we=E2=80=99ll need to either add = indirection, or ask users to just add their own fontification rules, if = it is really specific. We=E2=80=99ll see.=20 Function definition & call is totally reasonable. But adapting all the = major modes to use them is might be too big a change for emacs-29. Yuan