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.devel Subject: Re: Recent updates to tree-sitter branch Date: Tue, 27 Sep 2022 15:28:12 -0700 Message-ID: References: <87wn9srn9n.fsf@localhost> <87leq65v3t.fsf@localhost> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.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="25211"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel , Theodor Thornhill To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 28 00:29:25 2022 Return-path: Envelope-to: ged-emacs-devel@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 1odJ4u-0006Q2-Ue for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Sep 2022 00:29:24 +0200 Original-Received: from localhost ([::1]:46994 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odJ4s-0005KF-JZ for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Sep 2022 18:29:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60210) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odJ3p-0004AT-Jf for emacs-devel@gnu.org; Tue, 27 Sep 2022 18:28:17 -0400 Original-Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]:34324) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1odJ3n-0006K6-N0 for emacs-devel@gnu.org; Tue, 27 Sep 2022 18:28:17 -0400 Original-Received: by mail-pj1-x102a.google.com with SMTP id a5-20020a17090aa50500b002008eeb040eso2092039pjq.1 for ; Tue, 27 Sep 2022 15:28:15 -0700 (PDT) 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; bh=CuYJVzed2hZD0/iTNVMNcPe4TTXMMgdThh/pkiKTMr8=; b=nd6XAix8smsuwMS8YnKfb0TZ3aYHU3jEQ+VP4TfBDhRXc7Nl+8yS08Dx+/cmeKxE6V 14/MvFgKTNsECqeszroplyyIWR3am329EjerWt51rtvx0CG0D6TbSHVzIIU7F784DPG+ nWcdO12TRRHiu/YRZHrYDMtxXuX+Pmc2/pl8MlNER3p/BWRSoZCjOhZ9hskxHqJ/Zt6v Biqj47a5xcbqGb+Fpqt6C8UUmN9rFDYU4LuEAdr01O+eNN15mcCKL3XsL0ikYn+hjbCt s8w2lX6IE2zmh2legpuHekGdF71ABV3R1gKC9htBy8KlUa3hCH0Fqo5Qm3d25h8O+1Nc OIJw== 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; bh=CuYJVzed2hZD0/iTNVMNcPe4TTXMMgdThh/pkiKTMr8=; b=TjNtnM67EwAkMkW6u/bJblbaPgglQ9Z0l500/ZUV5S2rj92RPjSXvedCRfoXctRrev ZVsqeoNYXOkH50F9pfD7xT9cv1g/wqB8O/eWIFz/jgMLyB7qZ0bB7Sk7MpS+VsqLPDLH z0pL17xXeEHqcEpaUwb0IcejMLNGBsWfoyPPuUVAne+gEUfgN/Fqxv4avYaNJl7roUZE kBKiNP46SQFTGJzFJhm4iDV6yNZH4i1l/HL28Kq/h5FZC3Nh3Pwa57DeXTvVHzFUOMz5 vwNkuzlne8LpVV/HmeevriClex5cNIJmXdzHHVwWqmVX3NmsmJnj7fbNr12QYBgdTzct 6m0Q== X-Gm-Message-State: ACrzQf0FjSsFWldPhr2GEDBsEEeg9/4DtwnBEJl5tsmnydca7L5Jstuk wQF3u9Dg+gDtqiXrYxDKi2c= X-Google-Smtp-Source: AMsMyM67gtt+HRRGLUb8+o0GUhQC84zcPAXlZECzul3q2QTIV3shLak75++wWOf0DBNeezHOXWuCDg== X-Received: by 2002:a17:902:9046:b0:179:f884:7f82 with SMTP id w6-20020a170902904600b00179f8847f82mr3158163plz.157.1664317693934; Tue, 27 Sep 2022 15:28:13 -0700 (PDT) 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 b3-20020a17090a5a0300b00202aa2b5295sm3861pjd.36.2022.09.27.15.28.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Sep 2022 15:28:13 -0700 (PDT) In-Reply-To: <87leq65v3t.fsf@localhost> X-Mailer: Apple Mail (2.3696.120.41.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::102a; envelope-from=casouri@gmail.com; helo=mail-pj1-x102a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:296374 Archived-At: > On Sep 26, 2022, at 2:43 AM, Ihor Radchenko = wrote: >=20 > Yuan Fu writes: >=20 >>> treesit-font-lock-rules rules take a form of >>> (MATCHER FACENAME) or (MATCHER FUNCTION) >>>=20 >>> where MATCHER can only be a query. >>>=20 >>> Is there any reason why MATCHER in treesit-font-lock-rules cannot be = a >>> function with access to the fontified node? >>=20 >> Hmm, I=E2=80=99m not sure what do you mean. The whole thing passed to = treesit-font-lock-rules is a single query, and we can=E2=80=99t really = change the query syntax, that=E2=80=99s defined by tree-sitter. = Basically in a query you have patterns paired with capture names, if the = pattern matches to a node, that node is returned with corresponding = capture name tagged on it. For font-lock, we just use face names as = capture names, and when a query returns captured nodes, fontify the node = with its capture name, aka a face (or a function). >=20 > What I am asking is an extra dynamic condition in addition to the = query. > For example: > 1. Only apply FACENAME for nodes matching QUERY, but only when Elisp > variable is non-nil >=20 > 2. Only apply FACENAME for nodes matching QUERY, which are in the = second > half of the buffer >=20 > 3. Only apply FACENAME for notes matching QUERY, which also have a = field > matching a dynamically assigned regexp. >=20 > Essentially any condition that is not covered by the QUERY, but can be > checked in Elisp given that node object is passed to the test = function. These can be achieved by using a function, no? You do need to declare = global functions for them, but it shouldn=E2=80=99t be a problem. = Besides, as I said, the query syntax is not something we can change. The = freedom we have is how do we use the capture names. We can=E2=80=99t = extend the query with arbitrary lisp. >=20 >>> Further, can OVERRIDE FLAG of the MATCH-HIGHLIGHT as in >>> font-lock-keywords be supported? >>>=20 >>> "If OVERRIDE is t, existing fontification can be overwritten. If >>> keep, only parts not already fontified are highlighted. If prepend = or >>> append, existing fontification is merged with the new, in which = the new >>> or existing fontification, respectively, takes precedence.=E2=80=9D >>=20 >> I can do that, but would it be really useful? Unlike regex font-lock = which is used for so many different things, tree-sitter font-lock is, = IMO, only used to apply a base layer of language-specific highlight. How = would one use the override feature in this scenario? >=20 > For example, consider a function definition with docstring field. > Imagine that you want the function definition to have gray background, > but the docstring to have yellow background. OVERRIDE t is how this is > usually implemented in font-lock-keywords. The pattern that comes after will override patterns that come before. By = the nature of parse trees, for any node A and another smaller node B, B = is either completely contained in A or completely outside A. So I think = the override relationship is enough. Yuan=