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: Sat, 31 Dec 2022 01:41:14 +0200 Message-ID: <3ea7bb36-b524-1a39-598f-18d344826b0d@yandex.ru> References: <5d53b299-14e1-6f8b-58b3-7e16842d87a9@yandex.ru> <0f099d93-64c3-59be-9d5d-9b23ca1ecd2e@yandex.ru> <599B2C6F-C05F-4BB5-9509-2E07D848D573@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16776"; 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 Sat Dec 31 00:42:19 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 1pBP10-0004DW-89 for ged-emacs-devel@m.gmane-mx.org; Sat, 31 Dec 2022 00:42:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pBP08-0005K0-Iw; Fri, 30 Dec 2022 18:41:24 -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 1pBP04-0005JT-38 for emacs-devel@gnu.org; Fri, 30 Dec 2022 18:41:20 -0500 Original-Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pBP02-0005Rt-1u for emacs-devel@gnu.org; Fri, 30 Dec 2022 18:41:19 -0500 Original-Received: by mail-ej1-x630.google.com with SMTP id x22so54156645ejs.11 for ; Fri, 30 Dec 2022 15:41:17 -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=m+4Kdw8sJAdvkEDAj7VjYOlf0fD81z0S+J+avA9/tH8=; b=llmFDgmzOrQ9OvS5Eq5moxU92hiUiKW9JKUVV8ONEN9RW6qFZKtEtw5zHW5lHcOtkV eU1hKxSII/dUJd+lcP/f994huuDpN5CF9PZpaY27X2iCpPV/4643pe3VWNyc27m5fxgc FhZ23hrkx+kkr8L4vOjVKgNP3zDKDHNOyDgQ2+lt6u9SSWcr3Ev9mzec6kD7C34Il4iI Ci16ZNZxiVkESbrPtV6LXC/1UQMaLlqlVOgLYt5rEvj82eDntuldWC3V1it7qAngCEpm 11tagM8A0Zobcqp2L5PcrbFMq2tOuOXGT6Mfd3GOhAVg1CYmGkb2s8AR6O6vdCIYK1ht bc9g== 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=m+4Kdw8sJAdvkEDAj7VjYOlf0fD81z0S+J+avA9/tH8=; b=3VUjA4CM3mf52jgwYNBmAACR9KxL5umf/+zWmHIrpzHbDr/GiYY2RzhrpiAu2kx9pS d3wfZ/0Bp9NI8sFpFHswEW3Ig3/AeL7cc3I8W1GJ2cmj/szmAUttbmRUwnofaF6btq1S A18ZMk8Xc3k8ZVtYiEua7uLJIJ2EJKdg3A4ISzG0vuYKztOiZZ0wrQDHhrqXH1wBmXXh jgO8qfhIUpRJFNabu8UtWoMaoI+Uuy3JZaYpJaTQ8H2ByCEY6VjdPYiwWuHdza5a12NE KNBrHYBFDhl2nBwMFalyLt7YODAgLpaI6cPxRvW0WE9ekNflH29j9jouHfw7zyE/Hmf4 +3oA== X-Gm-Message-State: AFqh2kpJ+SDiy7oI4rQwerw0EPCn2bxwfuzC5AooDmrbmLHLD88fyaXV r+wnhPOY2v0JHl8Eg/gz6mg= X-Google-Smtp-Source: AMrXdXs0bnkJmZM1jBVUcc8BhvV/RdwcwyeOXc4iy9AENZD8Atbs83fXX1jD4lee+49bsNl+1xUMgA== X-Received: by 2002:a17:907:8dcb:b0:840:c37d:b5e4 with SMTP id tg11-20020a1709078dcb00b00840c37db5e4mr40382438ejc.16.1672443676477; Fri, 30 Dec 2022 15:41:16 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l18-20020a1709063d3200b0084c723b4c40sm4666024ejf.103.2022.12.30.15.41.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Dec 2022 15:41:16 -0800 (PST) Content-Language: en-US In-Reply-To: <599B2C6F-C05F-4BB5-9509-2E07D848D573@gmail.com> Received-SPF: pass client-ip=2a00:1450:4864:20::630; envelope-from=raaahh@gmail.com; helo=mail-ej1-x630.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.146, 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:302139 Archived-At: On 30/12/2022 13:16, Yuan Fu wrote: >> 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. > > Right now you can choose to highlight: > 1. Only definition identifiers, be it function, variable, class, etc > 2. All function identifiers > 3. All variable identifiers > > There could be better features, but the existing ones still have their merits. If you want a feature that highlights only funcalls, maybe we can add them, if there are enough time & interest. I'm mostly worried about having to duplicate font-lock rules between categories at this point. It just looks impractical to me. >> 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. > > If a major mode thinks highlighting all variables is the best default behavior, it can support the variable feature and put it at level 3. The standard list is just a guideline. So you're suggesting ruby-ts-mode changes treesit-font-lock-feature-list locally, and either moves 'variable' to a lower level, or adds a new category for said vars. We can do that, thank you.