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: Wed, 8 Feb 2023 17:44:19 +0200 Message-ID: <05ee38a5-f783-5b2c-add6-ee2ea27ba297@yandex.ru> 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; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35855"; 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, Jostein =?UTF-8?Q?Kj=C3=B8nigsen?= , 61302@debbugs.gnu.org To: Randy Taylor Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 08 16:45:27 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 1pPmdR-00097S-Re for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 Feb 2023 16:45:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pPmd9-0006Ra-Tt; Wed, 08 Feb 2023 10:45:07 -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 1pPmd4-0006Qe-Mu for bug-gnu-emacs@gnu.org; Wed, 08 Feb 2023 10:45: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 1pPmd4-0001Tc-CJ for bug-gnu-emacs@gnu.org; Wed, 08 Feb 2023 10:45:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pPmd4-0003g0-7C for bug-gnu-emacs@gnu.org; Wed, 08 Feb 2023 10:45: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: Wed, 08 Feb 2023 15:45: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.167587107314063 (code B ref 61302); Wed, 08 Feb 2023 15:45:02 +0000 Original-Received: (at 61302) by debbugs.gnu.org; 8 Feb 2023 15:44:33 +0000 Original-Received: from localhost ([127.0.0.1]:56357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pPmca-0003el-Ip for submit@debbugs.gnu.org; Wed, 08 Feb 2023 10:44:33 -0500 Original-Received: from mail-ej1-f44.google.com ([209.85.218.44]:37385) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pPmcW-0003eC-CT for 61302@debbugs.gnu.org; Wed, 08 Feb 2023 10:44:30 -0500 Original-Received: by mail-ej1-f44.google.com with SMTP id ud5so52240294ejc.4 for <61302@debbugs.gnu.org>; Wed, 08 Feb 2023 07:44:28 -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=6EvidSOb8JXvwR/euv17noWZUAYD2L7E7O1hbPOkLbU=; b=cJgy7LPpJtbGMTFrRXxFaqcv3f/GHM6Q/0O/1RHd1FjIMcIB5J1zXYES6iZx7OlWLh j3CqamwYiNpygsIvFKqoHm97vrEYEE8FhjqG000XUjY7YTaG1jmCfI+5SCeyJcOEDYsi mXj3I5rT/qONdQi1V5FQTYWV6K/0MZRPFSVuRC5166ibmx3ezP617ebj88FIm2v4Dn1L rGe7u+XRpJBp7FICV1PLKQqa51t/Plw4iz9YhZLVG7GGfkw8Axp3LeLoTDcXUJ2fwuEn 6JNu6DEYB5qls3aMb0AE095W7qQFsOtLSlxAVSdYkhkPFkbiD+SKL0SFrifuYB4cx3Rn NZWQ== 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=6EvidSOb8JXvwR/euv17noWZUAYD2L7E7O1hbPOkLbU=; b=XBLscH3H7j8tEAQ3E9BBoJxg7pLB9ji/OFXWW9lgEJS3tayeLhGXnE1JAcSaRHI3Mk yRze42phuf0Yd/NkK75PJnHSEhCbfGySDVV9LmbXPjtIZu6NFXaqFwD1Cbrsf6pyywL4 k8kAKdZNq7hCGc5iYiA5O6ua0EmcbHc27BiIvNmsIcgvOiLJCnnKr0aXJfoz74spvVzt 8odIhYOGFXvxgos1OEZ3C2fObRsvTAzXIyLG8LH4myDm6zMbF2Qbg70gv9o/pjA93FCs VAMuTQx6XRAEjptHfyMjFfwhK0JCbH54pIvlDlNU5B8FpqgfCIEpOL8E3ne2HxOobpbP oC7g== X-Gm-Message-State: AO0yUKXE1YDIeJwFPZOVKFhi5C4aMfZSrGlNfhfyMxjZhgC+KpIlJSn/ Q6rfGcmenymONX53bGyW0MQ= X-Google-Smtp-Source: AK7set/iQdXOanbPa51cdhz9hLUNHwjMm5CZgAUyTkMURAnJTMoMLShdBshznemiOlB9cNsJaWBjGA== X-Received: by 2002:a17:907:385:b0:878:67ad:cd8d with SMTP id ss5-20020a170907038500b0087867adcd8dmr3288878ejb.19.1675871062294; Wed, 08 Feb 2023 07:44:22 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id y19-20020a17090668d300b00880d9530761sm8422342ejr.209.2023.02.08.07.44.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Feb 2023 07:44:21 -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:255148 Archived-At: On 08/02/2023 05:38, Randy Taylor wrote: > On Tuesday, February 7th, 2023 at 13:25, Dmitry Gutov wrote: >>> 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 highlighted 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=61205#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 feature. > > That way, things like the following will be highlighted correctly: > let date = DateTime::::from_utc(date, chrono::Utc); > ^^^^^^ this guy > > Unless I'm missing something. Should Utc in the above example be highlighted with font-lock-constant-face too? What if it looked like this: let date = DateTime::::from_utc(date, chrono::utc); If we decide purely based on capitalization, then I guess the rule should be present in both lists (with capitalized? regexp in one, and !capitalized? regexp in another), and a few more rules should be duplicated as well. This becomes a little more painful semantically, given that the first 'utc' in the example above is parsed into a (type_identifier) node, not just (identifier). >> 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 = 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. So 'usize' in the above is definitely a "type", not a "module"? >> 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). If they're modules here, I suppose they should be highlighted the same in let row = usize::from_str_radix(...) as well. The bright side is that will make a more complex regexp (enumerating the lowercase named types) unnecessary.