From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Status update of tree-sitter features Date: Thu, 29 Dec 2022 18:38:24 +0200 Message-ID: References: <5d53b299-14e1-6f8b-58b3-7e16842d87a9@yandex.ru> <0f099d93-64c3-59be-9d5d-9b23ca1ecd2e@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12799"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: emacs-devel To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 29 17:39:24 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 1pAvwC-0003CM-50 for ged-emacs-devel@m.gmane-mx.org; Thu, 29 Dec 2022 17:39:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pAvvY-00046S-Hf; Thu, 29 Dec 2022 11:38:44 -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 1pAvvN-00042d-UU for emacs-devel@gnu.org; Thu, 29 Dec 2022 11:38:37 -0500 Original-Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pAvvK-0001P5-7q for emacs-devel@gnu.org; Thu, 29 Dec 2022 11:38:33 -0500 Original-Received: by mail-ed1-x533.google.com with SMTP id s5so27328515edc.12 for ; Thu, 29 Dec 2022 08:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=5/Vhpu4/pFKPeCYUAJLINx4X0ley+aDmDt1etUSplCs=; b=muQlC8MxFm3WRysWXDFIyLPmiIkmyC2pZvE/jfZ3ZFKWo1Ww0Bda2FrhmA0MvWxOHA 5c/0jAr/zpfpQ7qltAyer2OAdMw5XS3TC8D7JF2+s1/XeAQnQo9pPpeaeXMN+BZXfq2Q lWjonTdbkvCnCNkePOkdnBlHrpukgJut9adMPdog2YxoRj41BvIjdy+Ub80DrwE90ApO 88xKJhbn6XGSLtyd4W0S0e+Bup/V7wHSHigsvShSqJVy4C6U7+99DmPncMUiwzX+DhzH sbW3egL+mW4Q5jb2qq5Qo53ePKkMTCa7edWV4kdcZQExa0W207Qcu/lqMf2uqaI3EeJx MmkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5/Vhpu4/pFKPeCYUAJLINx4X0ley+aDmDt1etUSplCs=; b=29dDf7oERfWnzNoxGPz/uE6+JzUQTX0DdbWr3W5TKUL5RzJlDfVF5hHX2zF9qXqn8H pV7YaMdOsqQcvvHURh0zxxse8/TssMOw6X7eNGlyM47l3OvMQ47GdNUB8veDuEq9jBzj vDH0dDvIuzcRg7fCUY9Dq8xGTLkIDgC8FjXMdITTe91ROps3l/AQb4WjAMEzEbdvLOdG s/8dQcGDPjGpEI63OVJsEhsQ7McuHhuok+23gsnG4Q2reUTdACAnccJSA7OqbYs0/2MO 8uvJei401WtfIMWB19VVJ66a5bOOYnn1JJwvifA+M1slUoV/1CDtXCXEQGOC5CfpsHB4 fB7w== X-Gm-Message-State: AFqh2kq6YNYS7GVnZWgCk+bm4RAPfw/Xc4GdcbKB/uJcLnJ+wJ0yTyqT c1Ne6cekPD17V0drPAt+Y+Q= X-Google-Smtp-Source: AMrXdXuk2WWlvo3Kz/empM7doD1qEGyxJ8HtlNB6vFYEPhjHl884yJU/FPQR2VXMhTc+dyxWkzYhnA== X-Received: by 2002:aa7:d484:0:b0:468:ccfb:7201 with SMTP id b4-20020aa7d484000000b00468ccfb7201mr23411134edr.17.1672331907126; Thu, 29 Dec 2022 08:38:27 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id m2-20020aa7d342000000b00488117821ffsm2540474edr.31.2022.12.29.08.38.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Dec 2022 08:38:26 -0800 (PST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::533; envelope-from=raaahh@gmail.com; helo=mail-ed1-x533.google.com X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-1.149, 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302041 Archived-At: On 29/12/2022 11:21, Yuan Fu wrote: >>>> If it's only about calls, maybe call this category funcall? >>> Function, property and variable are for every occurrence of them (the touted “consistent highlighting”). So there will be a bit of overlap between function, variable, and definition. >> >> By "overlap", do you mean that font-lock rules should also have entries for variable/function definitions with category 'variable'/'function'? >> >> In case somebody removes 'definition' from their list of enabled features but keeps 'variable' and 'function' there? > > Basically, if you enable definition alone, you get highlight for function/variable/class definition. If you enable function/variable alone, you get highlight for all occurrence of function/variable identifiers, which would includ what definition highlights. Definition can be seen as the union of subsets of function & variable feature. Yes, but is that classification useful enough to justify the duplication in the font-lock rules' definitions? FWIW, I "broke" python-ts-mode in 8503b370be1, according to this definition. Sorry? But what do we get by this particular classification? The user will be able to disable 'definitions' and still have all function definitions highlighted? But not, say, variable definitions? That doesn't strike me as particularly more useful than e.g. disabling 'definitions' and having all function references highlighted (but not definitions). Which we would make possible by limiting 'function' to non-definitions. >>>>> variable every variable identifier >>>> >>>> 'variable', so far, seems like the least useful. When enabled, it lights up every bit of text that remained from other matchers -- because identifier are everywhere. >>> Yes, but apparently people want it ;-) >> >> Well, if they really do. >> >> I figured that people who added this maybe haven't tested this thoroughly. And that maybe they expected the effect of that "local variables highlights" feature that some editors showcase already. > > The purpose of the standard list is to regulate features, so if a major mode wants to support a feature in the list, it uses the definition and name from that list (rather than creating a feature with same definition but different name, or same name but different definition). If a major mode really want variable feature, they can add it, if not, they don’t have to. Okay, I also have a different, somewhat related question. Certain languages have a special syntax for "variables". Ruby has @instance_variable and $global_variable -- the @ and $ are used both during assignment and for later reference. Perl has $var and @array_var. PHP has $local_var. Up until now we've highlighted those with font-lock-variable-name-face. Except for @array_var in Perl, which has separate derived face. Either way, we did highlight them. What category should we use for them in ts-based modes? If it's 'variable', then won't be highlighted by default. If 'variable' matchers in other existing ts modes didn't include all identifiers everywhere, we could put 'variable' into level 3. Or we could add a separate category for all those, I guess. >>>> For Emacs 29, though, I would discourage the use of 'variable’. >>> It’s on level 4, meaning not enabled by default, so I think it’s fine. >> >> Fair enough. If someone wants function/property but not variable, they could fine-tune the list. > > Right. All the features in level 4 are pretty over-the-top IMO, so simply bumping to level 4 and enable everything is probably not the way to go. I actually considered having level 4 enabled. The punctuation faces look like 'default' without customization anyway, so it doesn't turn into angry fruit salad right away. One can stop at customizing the "brackets" face, for example. Though I'd probably also want 'function' and 'property' highlights to use other faces, distinct from 'function-name' and 'variable-name'.