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: Thu, 9 Feb 2023 23:19:08 +0200 Message-ID: <8a58c831-d8e6-c5b8-67b0-c606b2b3f189@yandex.ru> References: <6209c097-0369-828a-7513-d8afb73fd7f0@secure.kjonigsen.net> <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> <05ee38a5-f783-5b2c-add6-ee2ea27ba297@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="40693"; 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 Thu Feb 09 22:20:18 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 1pQEL4-000AOM-Ay for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 09 Feb 2023 22:20:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQEKr-000780-5B; Thu, 09 Feb 2023 16:20:05 -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 1pQEKo-00077U-LX for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2023 16:20: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 1pQEKo-0006qB-3A for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2023 16:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pQEKn-0008Av-Lf for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2023 16:20:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Feb 2023 21:20:01 +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.167597755931373 (code B ref 61302); Thu, 09 Feb 2023 21:20:01 +0000 Original-Received: (at 61302) by debbugs.gnu.org; 9 Feb 2023 21:19:19 +0000 Original-Received: from localhost ([127.0.0.1]:33849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQEK6-00089x-He for submit@debbugs.gnu.org; Thu, 09 Feb 2023 16:19:19 -0500 Original-Received: from mail-wr1-f41.google.com ([209.85.221.41]:44585) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pQEK5-00089h-7G for 61302@debbugs.gnu.org; Thu, 09 Feb 2023 16:19:17 -0500 Original-Received: by mail-wr1-f41.google.com with SMTP id bk16so3171037wrb.11 for <61302@debbugs.gnu.org>; Thu, 09 Feb 2023 13:19: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=W+tnP5/csNFH9uhhTXZQAoo5Sh0SVvkw5IfGGd6X+WQ=; b=JflnPUADa3WJnvhWPMdI6a6CeDjm02dlEt9RoQKH0qXU1qdydXpXhtosFPTl7PQQO9 R/HFg+jQq0ZvAtE+LA7Aqm9yQjlBQe8l4HTrew5LqEWv6JxGEGaBle4xXYJeprHIrjw0 9IWaFwKiDcEH4SuaUGsQQ20ZaXX3VkYOUlhSxIsMMsJuYV6xpdfdPrG4EeCc+1OhOmob xg6YPQCJAhH5/dTvovwfLYK/gWrWTm6Uvp0GxcNpCvehnTg94AbGwMJflsPxCMidtTbX tJOiiJ+40np3Sttr8ucIciHFTVy7sGVcUbmHlQ6QdmEMPuGnEkjBH3BrFCDSSHBxirsK 5oOA== 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=W+tnP5/csNFH9uhhTXZQAoo5Sh0SVvkw5IfGGd6X+WQ=; b=r4PzurNQRIdbt4xnk6x+sfq0vJhSv6A05U8HQe4YFc0D0NqXFIVIvCTTkJGuBVUh1x 50SzxSMBpszb0oXAP2s62eC2vCR9G6BKIOwWopj4rM2PJth04KNxl5lk7Alg7MdJ22Wh CDPSib/S7eiWZ4YxaYAQtXaa3lrQMrPbEWf9naGhbS4Tr3fTXtbMY5xxAQtExIvsAav8 +1vxSkYjyFgx+/xEAymHge0/C1e5idCj+1V32Rpa/XKlYJy5zWu6EycVJPw5m9QFRc36 RVelBJemUTIJKhCUXoNmZe4WTrIB2QNumFUlHfIlRZPtYjLGxojcBKIT7J0Oms8n/Ypk iYww== X-Gm-Message-State: AO0yUKUPo85rgSdOCNzQGtahXrBsW66NohVNU9c8TbaYp5gkAWiKHalF PWQFo66a8hKYQ+tOpMyLQXc= X-Google-Smtp-Source: AK7set9oNcDd4xZzw/9SzPX+GiXFE5Pm7QMhkbgs0bwG1tnh5+uhVpcm/hpkZb5wZJiFFQI8YyXFPA== X-Received: by 2002:adf:f647:0:b0:2c5:3e91:459a with SMTP id x7-20020adff647000000b002c53e91459amr2926357wrp.36.1675977550994; Thu, 09 Feb 2023 13:19:10 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id s9-20020adfecc9000000b002c3e9cce04csm2095803wro.111.2023.02.09.13.19.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Feb 2023 13:19:10 -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:255253 Archived-At: On 09/02/2023 05:38, Randy Taylor wrote: >> 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. > > In both cases, utc is still a type even if it's not capitalized. > My patch addresses this. So the end of a scoping chain must also be either a type or a method call? We might be able to use that, somehow. Though the 'use' declarations might be exceptions, e.g. use crate::foo::baz::foobaz;crate or use std::{fmt, fs, usize}; (fmt and fs are modules, not types). >> 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"? > > I think so. You can see on usize's documentation page (https://doc.rust-lang.org/std/primitive.usize.html) > that it provides that function, amongst many others. I was thinking that it might also be referring to (apparently deprecated) https://doc.rust-lang.org/std/usize/index.html. Sorry, I'm not really familiar with Rust. E.g. in Ruby every class can also serve as a "module" in the scoping sense. As a result we highlight both classes and modules with font-lock-type-face. This could also be an option here, if everything else fails. But we could also highlight based on a "role" (constant if it's used as a scope, and type if it's used as a type). Although one could say that 'Path' in Some(Path::new("./foo")) is being used as a type as well, and 'Some' too. So it might not be the best fit. Speaking of 'usize' again, what if some lib or the app defines an 'usize' module for its custom functions acting on it? E.g. 'my::app::usize'. A simple regexp matcher will probably highlight it as a type as well. >>>> 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. > > Yes, except for the primitives. > > I have attached a patch which I think addresses most of the concerns (although I've been at it for a few hours and my brain is mush now). > > The patch does the following: > - Separates import-related stuff and module use by leveraging the use_declaration query (simplifying things greatly IMO). > - Highlights primitive types used in scoped_identifiers. > - Properly highlights types belonging to a module no matter how deep it is (or your money back guaranteed!). > - Maybe some other stuff I forgot. I'm too tried now :). Thank you, I can sympathize -- this stuff gets complicated. Some problems from my testing: 1. If I keep treesit-font-lock-level at its default value (3), some stuff gets misfontified: use std::collections::hash_map::{self, HashMap}; 'hash_map' is highlighted as a type. 'HashMap' is not highlighted at all. use std::{fmt, fs, usize}; Only 'use' is highlighted here. test::test1(); 'test1' is highlighted as a type (we discussed this problem with highlighting types by default -- it becomes necessary to filter out function calls, either with more complex queries, or with custom highlighter functions). 2. If I switch to treesit-font-lock-level 4: let boxed_i32 = Box::new(5_i32); 'Box' is highlighted with font-lock-constant-face. I think it's a type, though. Also here's a pre-existing problem mentioned above: use std::{fmt, fs, usize}; 'fmt' and 'fs' are not types. But they are highlighted with font-lock-type-face. > A few questions: > - Should module be moved to level 3 to be with type? > - Do we still want the module feature, or should this stuff be put into type? I suppose we should iron some kinds out first to get a better understanding. But if it's all the same code complexity wise, it wouldn't be the worst idea to keep 'module' on level 4, so level 3's highlighting is still somewhat subdued.