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.bugs Subject: bug#61655: [Tree sitter] [Feature Request] font-lock function calls, definitions, separately Date: Sat, 25 Feb 2023 15:05:38 +0200 Message-ID: <1cd94489-7368-ce2c-0246-6a55c7fc5044@yandex.ru> References: <8DA1B548-B8D2-4EC1-B9F8-F7654003AC89@gmail.com> <56C0998E-3053-49F3-BAE3-46D6432B16F5@gmail.com> <87abbcaf-e60b-f975-b589-5e61f2d7866e@yandex.ru> <83bklkp7tj.fsf@gnu.org> <97710356-24c1-d79c-4796-3e51fd4809e3@yandex.ru> 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="27273"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Cc: casouri@gmail.com, 61655@debbugs.gnu.org, Theodor Thornhill , Eli Zaretskii , jacob.fai@gmail.com To: Randy Taylor Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 25 14:06:22 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pVuFp-0006zA-VU for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Feb 2023 14:06:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVuFY-0000Ah-88; Sat, 25 Feb 2023 08:06:04 -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 1pVuFW-00009m-Ug for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2023 08:06:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVuFW-0001PT-Lx for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2023 08:06:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pVuFW-0006gD-E2 for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2023 08:06:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Feb 2023 13:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61655 X-GNU-PR-Package: emacs Original-Received: via spool by 61655-submit@debbugs.gnu.org id=B61655.167733034825657 (code B ref 61655); Sat, 25 Feb 2023 13:06:02 +0000 Original-Received: (at 61655) by debbugs.gnu.org; 25 Feb 2023 13:05:48 +0000 Original-Received: from localhost ([127.0.0.1]:39330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVuFI-0006fj-FH for submit@debbugs.gnu.org; Sat, 25 Feb 2023 08:05:48 -0500 Original-Received: from mail-ed1-f49.google.com ([209.85.208.49]:38422) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVuFH-0006fX-3U for 61655@debbugs.gnu.org; Sat, 25 Feb 2023 08:05:47 -0500 Original-Received: by mail-ed1-f49.google.com with SMTP id cy6so7921180edb.5 for <61655@debbugs.gnu.org>; Sat, 25 Feb 2023 05:05:47 -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=v0383w8Zf+FlT1NKEaXJ0H3FtWBI9hlGc/nqAzJKeug=; b=UXhH69qA6tAd/vzrynushrIkKxiGvtzVHMY31tNT8JVXVsB/aBBB0U+CiFxouVxx0Y cSDsiGZc0QujJZHfsmC0a1uUAQ5lkQPaUnGmD3AG9RJczI1XY4S0zc+12AwyQHs2bzLU L3zdj3q+gTx28ofhWOm3Ir7hMAtBAvq0YtRs8edWilwYqDNxX9Vlqkmr2nmBuTSXuUKi DZzKgDJdlnEBQm3f3t8VE8H7Pw0lQTUnU1XNqtA4sRBrv0bFtFO8tjivKNdfm2uk86fm h+iwh3qDAoQHXkknsvq4eCTrHVcb7hSbr6NTxwLdjlG2WAr6AGvSORa0v4CjMS4k4ZBV r50g== 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=v0383w8Zf+FlT1NKEaXJ0H3FtWBI9hlGc/nqAzJKeug=; b=aJOyyZmRFVFsW/p/WJh+HyKzGbLpYXTJvozEPT1b49h12nxugC7a+UWRoVyIthmPDF 3+Q+25tkTJ6DItmLxnRTMDGE1wufvPjZdoBZQaCEmF+VrVgC4vt/n0c/YkV+4mUHVUDN +AwpJOqUPphxtf2c7yN2dWygPEFIfbQunMjlkWcIKafO+QMvTUqMfOlVSzDmNfL++dCZ W3BoDx/M2ryfEDb7VYYst5E6gfrOp5QsX9kd59lBo0mqpC7V7VxDCVRU52+NalmKUDxv bk9WFdAM0IMv9gnxPJWMrbHOjiqrp0E5RhzIFflrDSY2V35ExBmExQDGUdEQZKTkS5QX 0YRw== X-Gm-Message-State: AO0yUKX9EO34FT2srsZqd/iUBQSUicE8UG1JzxAZEn7i5qBeWFhrtexG rv2KitPUsSpiP2DJUF2+AjY= X-Google-Smtp-Source: AK7set90UpmtlleI+gaGFF10Fp3BQN2xfAGt1btI0B7h2Rl8YeL5HxBUH7dqvscPXrTtZa0VaED/Ng== X-Received: by 2002:a17:906:dc90:b0:8b1:304b:8e2c with SMTP id cs16-20020a170906dc9000b008b1304b8e2cmr37444446ejc.0.1677330341179; Sat, 25 Feb 2023 05:05:41 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n27-20020a170906089b00b008be5b97ca49sm805855eje.150.2023.02.25.05.05.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Feb 2023 05:05:40 -0800 (PST) Content-Language: en-US In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:256716 Archived-At: On 25/02/2023 05:59, Randy Taylor wrote: > It is a suitable term, but there is a confusing overlap, at least to me. In C++ parlance, for example, they are referred to as reference variables. I wasn't really getting down to the semantics of it, just when I see something like: > > void quack(int& thing) > ^^^^^ > obj_t& thing2 = otherthing; > ^^^^^^ > > Those are the things I would expect font-lock-variable-ref-face to highlight if I was just going off of the name, and I would expect many others to think the same. That's not unreasonable. > I don't have any better ideas than font-lock-{property,variable}-use-face, so I guess we can see if anyone else has any opinions on the matter. The only one I could think of is font-lock-{property,variable}-value-face. But that one can give wrong ideas as well. I suppose we should go with -use-, unless more alternatives are suggested. >>> Personally, I don't really see the value in differentiating these for variables. I can understand it a little more for properties. But I guess it doesn't hurt to add if folks want it. >> >> >> I see two potential uses: >> >> 1. Customize treesit-font-lock-level to 4 but >> font-lock-variable-ref-face to copy 'default' (or close to it), to skip >> variable reference highlighting or make it less noticeable. > > Wouldn't they just remove the variable feature if they want that? That's the obvious choice (which might be less accessible to those who don't venture into the manual, though, or don't write Elisp), but now they also have the option of toning down the highlights. >> 2. Pattern matching or comparably complex syntax which at a first glance >> may look like variable reference, but actually creates new bindings (or >> vice versa, creates new binding when one wanted to refer to an existing >> value). >> >> Emphasizing the difference can help people, beginners especially [in a >> particular language]. >> > > No doubt there are uses, I just don't really see them actually getting much use in practice. But maybe I'm wrong :). We'll see. I hope we will. Some third-party theme or two might start carrying that distinction, to start with. It might be nice to improve the default theme in that regard too, but that's a non-trivial task.