From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Randy Taylor Newsgroups: gmane.emacs.bugs Subject: bug#61302: 29.0.60; rust-ts-mode does not show function-invocation on field-properties Date: Wed, 08 Feb 2023 03:38:13 +0000 Message-ID: References: <6209c097-0369-828a-7513-d8afb73fd7f0@secure.kjonigsen.net> <5bd2f9f0-39d5-4d6b-815d-eda20d366441@app.fastmail.com> <32e34056-1a88-469a-819c-ae52e7d60712@app.fastmail.com> <3e40d23f-1629-c5b7-1f17-d769790d6494@yandex.ru> <56a0b3d9-4a8f-0f81-83cb-6b78271dd782@yandex.ru> <3dc0ab0a-b0b1-91b8-f393-8db3899cf956@yandex.ru> 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="35995"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, Jostein =?UTF-8?Q?Kj=C3=B8nigsen?= , 61302@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 08 04:39:25 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 1pPbIq-00099L-Ql for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 Feb 2023 04:39:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pPbIW-0000f7-Uu; Tue, 07 Feb 2023 22:39: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 1pPbIU-0000ep-QZ for bug-gnu-emacs@gnu.org; Tue, 07 Feb 2023 22:39:03 -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 1pPbIU-0001W0-Ci for bug-gnu-emacs@gnu.org; Tue, 07 Feb 2023 22:39:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pPbIU-0007JG-8m for bug-gnu-emacs@gnu.org; Tue, 07 Feb 2023 22:39:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Randy Taylor Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Feb 2023 03:39: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.167582751728059 (code B ref 61302); Wed, 08 Feb 2023 03:39:02 +0000 Original-Received: (at 61302) by debbugs.gnu.org; 8 Feb 2023 03:38:37 +0000 Original-Received: from localhost ([127.0.0.1]:54447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pPbI5-0007IU-2d for submit@debbugs.gnu.org; Tue, 07 Feb 2023 22:38:37 -0500 Original-Received: from mail-4323.proton.ch ([185.70.43.23]:32985) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pPbI2-0007IB-6N for 61302@debbugs.gnu.org; Tue, 07 Feb 2023 22:38:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjt.dev; s=protonmail2; t=1675827507; x=1676086707; bh=FhziJD2o83fU8jekaL+o8/ZZ4EGLWkwhhfaI0pUM29Q=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=vD/cetNg+/nGCrO4ovOzbb4h0Uhb9z/zdwORasvc8d8Y/qEY9s7dSHzgxBCg/xG2K YiBwTyzgX+beLrHQdsNV0PXqvjFvpWn01eqVKPN9d8K5fa7r6WZw6eUJcAUmSAC0F/ LffGZ8SeH4cf031cOxHeR7BDVAU0tnBjFiHfe6ybiOyPLiQncOhsOfbS/2lzs1NCA0 mO33fcZwOg9PSjmBaCozvJP+a2ds8jCR3DeVLjeKVJm05QzyYAIRaIAdzPaQZ1Aw3Z eeS4vDkQiXlNmj3hFdQRghzAOeFlzXIs6sUg/XhsVSn1xTFPUJdWcWBeT3Dw0ny3js Q0pObqLowBb9w== In-Reply-To: <3dc0ab0a-b0b1-91b8-f393-8db3899cf956@yandex.ru> Feedback-ID: 44397038:user:proton 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:255097 Archived-At: On Tuesday, February 7th, 2023 at 13:25, Dmitry Gutov wr= ote: >> rust-ts-mode looks good to me as well except the imports. Stuff like: >> use std::fmt::{Display, Formatter}; >> >> is highlighted incorrectly. In the above example, std and fmt are highli= ghted as variables. > >This is a result of 'variable' being implemented as it is now -- >highlighting all (identifier) nodes that no previous rule has matched. > >That makes things complicated when we try to support customizable >highlighting level where the user can mix and match the enabled features. > >With imports, there was also another problem which I mentioned here: >https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D61205#68 > >If we highlight the imports as constants on level 3, when the 'function' >feature is disabled, the function names will get highlighted with >font-lock-constant-face as well. That seems undesirable. > >But -- and this just occurred to me today -- if we create a separate >feature to add to level 4, with rules defined below 'function', that >should satisfy all the constraints. I think this is a good idea. > >> We should give them font-lock-constant-face. >> >> I will try to propose a patch later today unless someone beats me to it. > >Try the attached patch, please. Thanks, it looks good to me. I think the following rule from the type feature: (scoped_type_identifier path: (identifier) @font-lock-type-face) Should be changed to font-lock-constant-face and moved to the module featur= e. That way, things like the following will be highlighted correctly: let date =3D DateTime::::from_utc(date, chrono::Utc); ^^^^^^ this guy Unless I'm missing something. > >On a distantly related note, we have terms like 'usize' which is >normally a type (and highlighted as such), but can also feature in >expressions like > > let row =3D usize::from_str_radix(row, 10).map_err(|_| error())?; > >where it is now highlighted with font-lock-constant-face. Should we try >to do anything about that? If there is a limited number of built-in >types in that situation (e.g. all of them primitives), we could handle >that with a regexp. Right. I think it makes sense to handle the primitives with a regex. I'm not sure if there's anything else beyond those. There's a list of them here: https://doc.rust-lang.org/reference/types.html I think it would only apply to the numerical and textual types. > >Or vice versa, in > > use std::{fmt, fs, usize}; > >should 'fmt', 'fs' and 'usize' be highlighted with >font-lock-constant-face rather than font-lock-type-face? They should indeed be highlighted with font-lock-constant-face because they= are modules. We assume the types will be capitalized since that's all we can really do (= and it's the convention anyway).