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#61302: 29.0.60; rust-ts-mode does not show function-invocation on field-properties Date: Mon, 13 Feb 2023 21:57:49 +0200 Message-ID: <004dc5d0-7062-bda1-8a14-2bf16d986e24@yandex.ru> References: <6209c097-0369-828a-7513-d8afb73fd7f0@secure.kjonigsen.net> <56a0b3d9-4a8f-0f81-83cb-6b78271dd782@yandex.ru> <3dc0ab0a-b0b1-91b8-f393-8db3899cf956@yandex.ru> <05ee38a5-f783-5b2c-add6-ee2ea27ba297@yandex.ru> <8a58c831-d8e6-c5b8-67b0-c606b2b3f189@yandex.ru> <48016e5e-71e0-c94f-4927-ee0c7b2aaa1e@secure.kjonigsen.net> 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="30317"; 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: eliz@gnu.org, 61302@debbugs.gnu.org To: Randy Taylor , jostein@kjonigsen.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 13 20:59:14 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 1pReyn-0007lo-SY for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Feb 2023 20:59:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pReye-0002MP-FB; Mon, 13 Feb 2023 14:59: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 1pReyc-0002Kf-T6 for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2023 14:59: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 1pReyc-0004ut-Kr for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2023 14:59:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pReyc-0005pS-Cu for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2023 14:59: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: Mon, 13 Feb 2023 19:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61302 X-GNU-PR-Package: emacs Original-Received: via spool by 61302-submit@debbugs.gnu.org id=B61302.167631828422333 (code B ref 61302); Mon, 13 Feb 2023 19:59:02 +0000 Original-Received: (at 61302) by debbugs.gnu.org; 13 Feb 2023 19:58:04 +0000 Original-Received: from localhost ([127.0.0.1]:51684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRexg-0005o9-2L for submit@debbugs.gnu.org; Mon, 13 Feb 2023 14:58:04 -0500 Original-Received: from mail-wm1-f53.google.com ([209.85.128.53]:43557) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRexd-0005nf-UE for 61302@debbugs.gnu.org; Mon, 13 Feb 2023 14:58:02 -0500 Original-Received: by mail-wm1-f53.google.com with SMTP id az4-20020a05600c600400b003dff767a1f1so9912325wmb.2 for <61302@debbugs.gnu.org>; Mon, 13 Feb 2023 11:58:01 -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=awutBpJkW0CJOkQL/2p207pFfecYKTpWcprMz9I7e7A=; b=hgXHBfi1FWlchpWjytnQ5s2J/rXzS0R8Tadxi4oH2qmsQHX9QjKrvG0Fr5ejPfg5dU LcI+V9mQIBqn7RCbvgDzwp/wM0/sTKeY6xVaqjUtx4CIBZQ0n16JScmrx2BGSpjU4KqU 2PeThCZMeuuqthREQVCpj6WEJqINHku3/u1BMlfaR8vWKFGk5kubzCxRo9ccZ0THjKot Ro300anJ9ioaI3AVtFZSUtT7+/yRl87vhqvmL93bQc/fNVyprqjZzWRS34yYll7oNlod BQ0cPytV/f7xVwqB5aDJYsvaoxwbUKhgeM6Ry/DP5tv4w0Ax71xbjxHMsWwKx99ahOt+ Vhhw== 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=awutBpJkW0CJOkQL/2p207pFfecYKTpWcprMz9I7e7A=; b=oX+TSf/gx+ko/691GCuEs05AfyQcijX9owUHNsc3uKjNNcnDcmnMVbFuAQ28QwDcTU RJe0LH5jgUSZz8wUgqvyA9IPM+HswWHrTtx84SfRBU1hFZtO7iREq/u/XvHbowMO/Vg3 v5SBLgKwexD7xPfVjRghqccNGZMXmk/yKFq1tIRmsoQYEg+7/3IGx+Pp/oQ78iRLa6aQ Ep5G36xpRsEKsIGArwBfPKEih2oR7yBjW+smRYCvgD3MCELK5HXVyt/oyjh2ACXyf1UZ O0lwVaAwhy8kpDwgoKR8sH4rW6EsFl0ywYBPgfWFuSktCdXrcETih5PIBSyOOKjNveGb iZNg== X-Gm-Message-State: AO0yUKV1C0Lwci7kTalyRKqhwFuGZwdEkJUhy5gwlt7OLajwww5iTcU8 z2twNqYd7uTuCNyToKdMIno= X-Google-Smtp-Source: AK7set9vh5Uc7/CDNTQnjGox0QsluljtsKV3RyDLfk66seSVRnKQX4PGrR4Pp/O7Y1Q00wbrVmxCjA== X-Received: by 2002:a05:600c:3511:b0:3df:9858:c03a with SMTP id h17-20020a05600c351100b003df9858c03amr7018819wmq.15.1676318276100; Mon, 13 Feb 2023 11:57:56 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id bi5-20020a05600c3d8500b003db012d49b7sm23584292wmb.2.2023.02.13.11.57.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Feb 2023 11:57:55 -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:255519 Archived-At: On 13/02/2023 16:39, Randy Taylor wrote: >> >>>From what I can tell, neither of them is perfect yet, but they both get some things right: >> >>    rust-ts-mode: function invocations :) >>    rust-ts-mode handles constants better (also escape-sequences, but not seen in this sample) >>    rust-mode: consistently fontify annotations (notice they are missing in rust-ts-mode, line 12 and 14). Also rust-mode use font-lock-preprocessor-face, which I think as a more appropriate face for this kind of syntax, than font-lock-constant-face (used in rust-ts-mode). >>    rust-mode: is able to handle nested macro-invocations. See line 42 and 44 above. From what I can tell, this seems to be due to a short-coming in the tree-sitter grammar for rust, and we may be able to fix it upstream, instead of monkey-patch things based on regexp's in rust-ts-mode >> >>As for things which are less great in rust-ts-mode: >> >>    some code does not seem to get fontified at all (types, keywords, etc). Line 14-17. > > Did you look at that with treesit-explore-mode? > It's inside a macro invocation which mostly consists of token_trees. > Not much helpful stuff for us to go on to highlight. Depending on the progress in improving the grammar, we could choose to add some ad-hoc Lisp based fontification to macro calls (using something similar to what rust-mode already does, I guess). There's no hurry for that, though. Certainly not before Emacs 29 is out. >>    it seems to fontify all variables using font-lock-variable-name-face all over, regardless of it is a declaration or not. I realize this is not 100% consistent throughout the Emacs-verse, but I know other -ts-modes have aimed for declaration only, and so does rust-mode from MELPA too (although with some consistency-issues) which this would be replacing. > > Because that's what the variable feature is supposed to do, same as the > function feature. > Perhaps rust-ts-mode's definition feature can be augmented to support > that That should already work. Either try treesit-font-lock-level=3, or use level 4 but follow it with disabling the 'variable' feature, and you'll see variable bindings highlighted. In function parameters and let/for/match expressions. > (and also note it's missing an assignment feature that some other > modes have). I didn't bother with assignments for now (in the absence of feature requests), but they should be even easier to add. Overall, I would recommend to drop the 'variable' feature as it is now (sorry for repeating myself), because if we reach the state where *everything but* variable references is already highlighted with some face, the variable references will stand out automatically (only they will be rendered with 'default' face). Adding font-lock-variable-name-face drops the distinction between a definition and a reference. But I don't want to force this subject: if you like it enough, no problem. The users can disable it manually as well.