From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jostein =?UTF-8?Q?Kj=C3=B8nigsen?= 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 16:04:57 +0100 Message-ID: <7392c27d-0d5b-e3e9-ccd0-3d4bf329986c@secure.kjonigsen.net> 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> Reply-To: jostein@kjonigsen.net Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------0i660umotCjx0thHIN1hYPYR" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16687"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Cc: eliz@gnu.org, 61302@debbugs.gnu.org, Dmitry Gutov To: Randy Taylor Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 13 16:06:45 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 1pRaPj-00048a-FI for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Feb 2023 16:06:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pRaP6-00044e-DS; Mon, 13 Feb 2023 10: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 1pRaP4-00044G-Ss for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2023 10: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 1pRaP4-0001oF-Kl for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2023 10:06:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pRaP4-0007E5-E5 for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2023 10:06:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jostein =?UTF-8?Q?Kj=C3=B8nigsen?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Feb 2023 15:06: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.167630070827711 (code B ref 61302); Mon, 13 Feb 2023 15:06:02 +0000 Original-Received: (at 61302) by debbugs.gnu.org; 13 Feb 2023 15:05:08 +0000 Original-Received: from localhost ([127.0.0.1]:51219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRaOB-0007Cs-M7 for submit@debbugs.gnu.org; Mon, 13 Feb 2023 10:05:08 -0500 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:59861) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRaO8-0007CH-W9 for 61302@debbugs.gnu.org; Mon, 13 Feb 2023 10:05:05 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D12435C0108; Mon, 13 Feb 2023 10:04:59 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 13 Feb 2023 10:04:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= secure.kjonigsen.net; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:sender:subject:subject:to:to; s=fm3; t= 1676300699; x=1676387099; bh=4DN1Cj6sEoNW5CNvCmjIaEflbOAZH9OdDMb 5PVMo7QI=; b=cDUFadinWE+8B1QbGQkiU+K4sPyWMOq5rNTXY5yqihvo+mBYryD KDMcOi0yEw6rf1iNZ/OQuzMgV0HR1JdBqj8sZzB/JJBTbQUWfni3CVeqQqlyW4c4 /IxO4ZBjQkufy/I7R12DmfsYhjahSGsus+eTnTaDgknh9jy5IMmzpx6FWHobfFBX VcfnD6WYw8Cgpw1WDghuqEqy6GVjlO9EBrYbsnBJFchmz5SOuHd4z4pNCIiDt2Fs 2A12LxXQD+LydjiyV+n0a3U3SWrY6q2EdMKTeuUEiXQoB5zmYuXeNsJNjtMRCiaf uOt1Nd4tub76QeoKkplhql+9kmMVsRireqw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1676300699; x=1676387099; bh=4DN1Cj6sEoNW5 CNvCmjIaEflbOAZH9OdDMb5PVMo7QI=; b=K637qKxvlo4mvkaWrGB4XI/SFdWp4 0AQPf3LsDVbM8Y4JFNeTvr8JNW7bf2RbEl0CZGuzwB9nciCY5Ap44/+TbiK5GGUJ Qn3OUJXAlEKOKyq3j36YXhSUzP1Q6+lG06EdvBFo3sYv9I8FTZkWGxIxFcUhYOsT 5z4nSTrLFasva84Rl3FuWqnXAuCDXK70hZwNQSfe7/33qPB8MWiDvM68r+MNUhDB 8rpqCV1txxGujBRj1bzy1EnJY5rReZ/5LWdD+XUCIp7gW6CUz5tyy7ZTTpP9BEop mHPpKq3HTKQZiSKDo2H+gB9MtJl9q6qxXZulntoKHzj+9+imlRJiy7ODg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudeiuddgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfkffggfghruffvvehfhfgjsehmtderredtfeejnecuhfhrohhmpeflohhs thgvihhnucfmjhppnhhighhsvghnuceojhhoshhtvghinhesshgvtghurhgvrdhkjhhonh highhsvghnrdhnvghtqeenucggtffrrghtthgvrhhnpeelieehgfevfeffleekleelffff tdefveelteehfefgtdfgtdefieevkefgveekvdenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehjohhsthgvihhnsehsvggtuhhrvgdrkhhjohhn ihhgshgvnhdrnhgvth X-ME-Proxy: Feedback-ID: ib2f84088:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 13 Feb 2023 10:04:58 -0500 (EST) Content-Language: en-GB, nb-NO 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:255498 Archived-At: This is a multi-part message in MIME format. --------------0i660umotCjx0thHIN1hYPYR Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/13/23 15:39, Randy Taylor wrote: > In the future, it would've been nice to have bug reports filed for > these regardless. > Especially since I had time last week to sink in to fixing these > problems... I'll try to keep that in my for the future. But registering "high quality" bug-reports takes some effort too, and I feel like just rushing them because -I- lack time may come off as impolite. > > I have been comparing to rust-mode, both now and when I was making > rust-ts-mode. Ok. Sorry for missing it. My bad :) > > Thanks. I wish you also would've included the code as text so I didn't > have to type it all out :). Indeed. Where -are- my manners? Attached is the original source file! > > >    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). Since this wasn't really mentioned in the reply... Any chance we can give font-lock-preprocessor-face some love too? Or should I make that a bug of its own? > >    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. Like I said. Might need to be fixed upstream in the tree-sitter rust grammars. I guess it seems like the rust-grammar in general could use some improvements... > > >    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 (and also note it's missing an assignment feature that some other > modes have). Right. Like I said, the Emacs-verse is not really 100% consistent about that, and I doubt it ever will be. Personally I was asked to remove such fontification when submitting changes/improvements to typescrip-ts-mode and csharp-ts-mode... And in the end I think I like the results more that way, and just assumed this was supposed to be the standard. Oh well. > > >    it does not seem to handle ::* imports properly? See line 9. The way I understand it, things preceeding the > ::* should be considered a namespace too? > > Correct, I will fix that as part of my next patch I post. > Before, we weren't distinguishing imports and general scope > identifiers which caused a lot of inconsistencies. Now we do, so it's > just a matter of rounding up all the import-related queries. Sounds great! > > >    I know imports are difficult to be 100% accurate about, as seen in this thread. Are we importing a module or > a class? Impossible to tell without looking at the referenced code! > Aiming for visual consistency may be a better goal than 100% > correctness, if the AST we're getting don't provide good enough > information? (This has been done in other modes too) > > That is what we're trying to do. I believe the patch I posted earlier > in the thread covers most of these cases, minus the wildcard one you > mentioned (which I will post a new patch addressing sometime later > today). If you notice any others, please shout. Sure thing. > > I don't understand this. So there may be a few things missing or a few > inconsistencies - so what? People can make bug reports for them and > they can be fixed. rust-mode itself has inconsistencies and > correctness issues as well, and other ts modes do too (like > c/c++-ts-modes WRT macros). I don't know. My WASM code may not have been the most typical rust code and as such may not serve as a great baseline for fontification? I just assumed if it would be much work to fix up, it might be hard to make the required fixes in time. If you (as one of the main implementers) disagree, who am I to argue? :) -- Jostein --------------0i660umotCjx0thHIN1hYPYR Content-Type: text/rust; charset=UTF-8; name="lib.rs" Content-Disposition: attachment; filename="lib.rs" Content-Transfer-Encoding: base64 ZXh0ZXJuIGNyYXRlIGNmZ19pZjsKZXh0ZXJuIGNyYXRlIHdhc21fYmluZGdlbjsKCm1vZCB1 dGlsczsKCnVzZSBjZmdfaWY6OmNmZ19pZjsKdXNlIHdhc21fYmluZGdlbjo6cHJlbHVkZTo6 KjsKCmNmZ19pZiEgewogICAgLy8gV2hlbiB0aGUgYHdlZV9hbGxvY2AgZmVhdHVyZSBpcyBl bmFibGVkLCB1c2UgYHdlZV9hbGxvY2AgYXMgdGhlIGdsb2JhbAogICAgLy8gYWxsb2NhdG9y LgogICAgaWYgI1tjZmcoZmVhdHVyZSA9ICJ3ZWVfYWxsb2MiKV0gewogICAgICAgIGV4dGVy biBjcmF0ZSB3ZWVfYWxsb2M7CiAgICAgICAgI1tnbG9iYWxfYWxsb2NhdG9yXQogICAgICAg IHN0YXRpYyBBTExPQzogd2VlX2FsbG9jOjpXZWVBbGxvYyA9IHdlZV9hbGxvYzo6V2VlQWxs b2M6OklOSVQ7CiAgICB9Cn0KCiNbd2FzbV9iaW5kZ2VuXQpwdWIgZm4gc2hvdWxkX2hhbmRs ZSh1cmw6IFN0cmluZykgLT4gYm9vbCB7CiAgICBpZiB1cmwuZW5kc193aXRoKCIuY3NzIikK ICAgICAgIHx8IHVybC5lbmRzX3dpdGgoIi5qcyIpCiAgICAgICB8fCB1cmwuZW5kc193aXRo KCIucG5nIikKICAgICAgIHx8IHVybC5lbmRzX3dpdGgoIi5qcGciKQogICAgewogICAgICAg IGZhbHNlCiAgICB9IGVsc2UgewogICAgICAgIHRydWUKICAgIH0KfQoKbGV0IHJlc3VsdCA9 IGZvcm1hdCEoInt9e30iLAogICAgIldlbGwgeWVzIiwKICAgIGZvcm1hdCEoIk9yIHt9IG5v PyIsICJwb3NzaWJseSIpKTsKCiNbd2FzbV9iaW5kZ2VuXQpwdWIgZm4gcGFnZSh1cmw6IFN0 cmluZykgLT4gU3RyaW5nIHsKICAgIGh0bWwoCiAgICAgICAgaGVhZGVyKCZmb3JtYXQhKCJ3 YXNtLXBhZ2U6IHt9IiwgJnVybCkpLAogICAgICAgIGJvZHkoZm9ybWF0ISgKICAgICAgICAg ICAgInt9e30iLAogICAgICAgICAgICAiPHA+SGVsbG8gZnJvbSBSdXN0ICZhbXA7IHdhc20h PC9wPiIsCiAgICAgICAgICAgIGZvcm1hdCEoCiAgICAgICAgICAgICAgICAiPGZvb3RlciBz dHlsZT1cImNvbG9yOiAjY2NjY2NjXCI+Q29weXJpZ2h0IEpvc3RlaW4gS2rDuG5pZ3NlbiAt IHt9PC9mb290ZXI+IiwKICAgICAgICAgICAgICAgICZ1cmwKICAgICAgICAgICAgKQogICAg ICAgICkpCiAgICApCn0KCmZuIGhlYWRlcih0aXRsZTogJnN0cikgLT4gU3RyaW5nIHsKICAg IGhlYWQoZWxlbWVudCgidGl0bGUiLCB0aXRsZSkpCn0KCmZuIGh0bWwoaGVhZDogU3RyaW5n LCBib2R5OiBTdHJpbmcpIC0+IFN0cmluZyB7CiAgICBlbGVtZW50KCJodG1sIiwgJmZvcm1h dCEoInt9XG57fSIsIGhlYWQsIGJvZHkpKQp9CgpmbiBoZWFkKGNvbnRlbnQ6IFN0cmluZykg LT4gU3RyaW5nIHsKICAgIGVsZW1lbnQoImhlYWQiLCAmY29udGVudCkKfQoKZm4gYm9keShj b250ZW50OiBTdHJpbmcpIC0+IFN0cmluZyB7CiAgICBlbGVtZW50KCJib2R5IiwgJmNvbnRl bnQpCn0KCgpmbiBlbGVtZW50KG5hbWU6ICZzdHIsIGNvbnRlbnQ6ICZzdHIpIC0+IFN0cmlu ZyB7CiAgICBmb3JtYXQhKCI8e30+e308L3t9PiIsIG5hbWUsIGNvbnRlbnQsIG5hbWUpCn0K Cg== --------------0i660umotCjx0thHIN1hYPYR--