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: Thu, 29 Sep 2022 12:01:17 +0800 Message-ID: <87k05m96cy.fsf@localhost> References: <87wn9srn9n.fsf@localhost> <87leq65v3t.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="15754"; 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 Thu Sep 29 06:02:06 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 1odkkQ-0003ql-D2 for ged-emacs-devel@m.gmane-mx.org; Thu, 29 Sep 2022 06:02:06 +0200 Original-Received: from localhost ([::1]:44520 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odkkO-000458-Se for ged-emacs-devel@m.gmane-mx.org; Thu, 29 Sep 2022 00:02:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37528) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odkir-0003Nt-Tr for emacs-devel@gnu.org; Thu, 29 Sep 2022 00:00:30 -0400 Original-Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]:38415) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1odkip-00088P-W4 for emacs-devel@gnu.org; Thu, 29 Sep 2022 00:00:29 -0400 Original-Received: by mail-pf1-x436.google.com with SMTP id a29so350821pfk.5 for ; Wed, 28 Sep 2022 21:00:27 -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=jOOj75MIgFZQN4H3k/SFStOcNLL1dux1zXdp85YX7BI=; b=WmUHzPIK2HhrxqCH+EY1KD2zf7ffQrwfL8e+P2q+eC1SR6Bp7kuegk4EN1CXVQbVk/ JaIGvoc2uMJQmGEGVyOPBKLNt177LIJe8+pRngpADN42pg17xr8S1vLq5kpd+mscA6R6 623TLb6xiYB7cx08oT18POQ5OK/IlTy7bxC5lbdMclRsQIrdDGPgUxLoI1F+3TOEl+Qy 1Y6h6QGtNBgw0UR4okTdWtHL+JP6TiXF0eJ6anW3w9KsG62bBB9xercouXFwGN3LRvG0 DjYjGUVaa37K/VJV08bieIrJtMwUwKgVmRdO6ZIE1/DO1ZjCBKJkRP3v9bsAGZx7aZwc Wo7Q== 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=jOOj75MIgFZQN4H3k/SFStOcNLL1dux1zXdp85YX7BI=; b=o3qUWuUSiYjENYpIaFKgP0kU+PPxcZVLra6n569StHjofJ1jmz/evYtddf2aoaZSlc TxRQ8f3uF4spepmapJ0THXmInMIOiOZIgUvaCMWO1s8Lhj5XzZ3TkAli4Z+6XmsqTkud 0UzHkgY/bfpoYw8tUUo3omG5TVBgklqVcPtOL2Hhhg/2wpX0/KxbTEVAAHGsdiT4slrA oksb/S/J9TKnYloKmiGJssWzkCuXhiuw5MKqE12f+TOWTjQLcy7+9ey/Dxggk/lY8I7W KzYHhQY1lIt6HKcwU/tyBSPSzmeN8KGOHvIydjBebv6pVfpvf0VKLk+5cDuTvx+Xp+ZK 1emg== X-Gm-Message-State: ACrzQf06neYKJSCMS/g9JDTEWYEqQAbsRNbkyLcjCAI8iICmsNADKVgE 0BXHxR8fHZ1SSxzkflD+cE0= X-Google-Smtp-Source: AMsMyM5yVSC2fuBJ3NF3+chMtCZHFPqkd/w8psTOCN22ujMGfGpNtpac7qMAWOiYcm+VBOy9UfedgQ== X-Received: by 2002:a63:e103:0:b0:438:de8d:f799 with SMTP id z3-20020a63e103000000b00438de8df799mr1114721pgh.239.1664424026341; Wed, 28 Sep 2022 21:00:26 -0700 (PDT) Original-Received: from localhost ([2409:8970:a80:3a4:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id n26-20020a63971a000000b0043b565cb57csm4407006pge.73.2022.09.28.21.00.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Sep 2022 21:00:25 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::436; envelope-from=yantar92@gmail.com; helo=mail-pf1-x436.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:296439 Archived-At: Yuan Fu writes: >> 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 glo= bal 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 hav= e is how do we use the capture names. We can=E2=80=99t extend the query wit= h arbitrary lisp. Will the currently matched node be passed to the function? Or should the function run yet another query to determine the node it was called on? >>>> 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 wh= ich is used for so many different things, tree-sitter font-lock is, IMO, on= ly 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 ov= erride relationship is enough. OVERRIDE can also be 'prepend or 'append to combine faces from multiple nodes. Also, OVERRIDE nil will not apply fontification on the already fontified parts of the region. Note that the parent node might only fontify fraction of the text inside the child node. The parts not yet fontified can make use of OVERRIDE nil. --=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