From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Recent updates to tree-sitter branch Date: Mon, 26 Sep 2022 17:43:34 +0800 Message-ID: <87leq65v3t.fsf@localhost> References: <87wn9srn9n.fsf@localhost> Mime-Version: 1.0 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="9941"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel , Theodor Thornhill To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 26 11:59:53 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 1ocku1-0002Rs-68 for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Sep 2022 11:59:53 +0200 Original-Received: from localhost ([::1]:53578 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ocku0-00033c-0o for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Sep 2022 05:59:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36778) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ockdR-0003uq-Jl for emacs-devel@gnu.org; Mon, 26 Sep 2022 05:42:45 -0400 Original-Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e]:34524) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ockdP-0001qq-OZ for emacs-devel@gnu.org; Mon, 26 Sep 2022 05:42:45 -0400 Original-Received: by mail-pj1-x102e.google.com with SMTP id a5-20020a17090aa50500b002008eeb040eso12231034pjq.1 for ; Mon, 26 Sep 2022 02:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=iioIfkdrzzXhYTpAkdSwRITtDZHYx4ZsZX4VC8IZHYA=; b=i9FvPqptlBGN5QHi5P9E7atoJiOgzwCE9V3UDZcyCe6cZi71vskeTR2WwIx6CLq/Qp yKWaqz+R3Rrv6ZsLyANNoe4RojHJpZscrDOISre6Q754fjd92NTQXigEnp7APW9o+C5l YIBJcfDcp4WNNTr8l58BcGGa6uoHIBGINmdHilK/acvLDyBz0kNQVvyMl8ZqDjCFfEN5 i5Rh60ahSu/h9XBahIf05vqihTD3UOA8+T1NTEzXBQCogl33YIiG7j4R0vWvLOVfcTEN B9PkLZBkS50Zka8QpSr+SgeJ0YCLGwXR9b+EfEj0ZTRIEdr+/S55t2idevzwZyuYFRXr CBsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date; bh=iioIfkdrzzXhYTpAkdSwRITtDZHYx4ZsZX4VC8IZHYA=; b=BxCktV0Qkmc3UoMyqSHHgmYk3b2l+wtEtOr+AObCWOYMocYoJkj/ORCjVQBac/v127 gPbFrmdz/0LwA5/s+KJc3kZyM4Ya+NuYNJBNJzV/pinEdXA9vbWdfXeneEfGlVG/nt8h HSzJ+Fd70WGVe+m0Fq+oUuIsMXLJBdUv7ODxEScmp1VwjrYlivWfhzOjwSEZ9lCfywCy 71nwhxuHXkFUTp4IyzDcYOsQzbC2olBP6xiv5RWgW8DJvJialh44KPzw55nFoYjbBm84 vAW8SR4L+I0hwdfk4PBfPuW6RzbMKfQpLgYErMdNG1dTUXUMzLKjCOYgdpIh3zef/PQh vLGA== X-Gm-Message-State: ACrzQf3RAiOZuNY0i9cI5+YB5ZvQA53z6Mjk7ty3QdyAV1aoYgD8Gd9B jqXamnEfAy4LmZKSHvp+2Bg= X-Google-Smtp-Source: AMsMyM694vyv1qw6FocY9ZQ4JkNB45wToEUBbeHbjCuzU032dmXM3f5sWOX7bci3ynga+v9/9gv11Q== X-Received: by 2002:a17:903:22d0:b0:177:e5b2:c598 with SMTP id y16-20020a17090322d000b00177e5b2c598mr21161287plg.56.1664185362139; Mon, 26 Sep 2022 02:42:42 -0700 (PDT) Original-Received: from localhost ([115.154.175.57]) by smtp.gmail.com with ESMTPSA id c5-20020a170903234500b001755f43bc22sm10818164plh.175.2022.09.26.02.42.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Sep 2022 02:42:41 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::102e; envelope-from=yantar92@gmail.com; helo=mail-pj1-x102e.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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_ENVFROM_END_DIGIT=0.25, 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:296271 Archived-At: Yuan Fu writes: >> 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? > > Hmm, I=E2=80=99m not sure what do you mean. The whole thing passed to tre= esit-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 que= ry 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 re= turns captured nodes, fontify the node with its capture name, aka a face (o= r a function). 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 2. Only apply FACENAME for nodes matching QUERY, which are in the second half of the buffer 3. Only apply FACENAME for notes matching QUERY, which also have a field matching a dynamically assigned regexp. 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. >> 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 n= ew >> or existing fontification, respectively, takes precedence.=E2=80=9D > > I can do that, but would it be really useful? Unlike regex font-lock whic= h 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 u= se the override feature in this scenario? 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. --=20 Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92