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: Mon, 13 Feb 2023 18:19:02 +0000 Message-ID: References: <6209c097-0369-828a-7513-d8afb73fd7f0@secure.kjonigsen.net> <05ee38a5-f783-5b2c-add6-ee2ea27ba297@yandex.ru> <8a58c831-d8e6-c5b8-67b0-c606b2b3f189@yandex.ru> <48016e5e-71e0-c94f-4927-ee0c7b2aaa1e@secure.kjonigsen.net> <7392c27d-0d5b-e3e9-ccd0-3d4bf329986c@secure.kjonigsen.net> 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="35066"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, 61302@debbugs.gnu.org, Dmitry Gutov To: jostein@kjonigsen.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 13 19:20:16 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 1pRdR1-0008vO-H7 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Feb 2023 19:20:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pRdQp-0007jx-Nw; Mon, 13 Feb 2023 13:20:03 -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 1pRdQo-0007it-H1 for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2023 13: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 1pRdQo-00046n-77 for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2023 13:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pRdQo-0002uN-4X for bug-gnu-emacs@gnu.org; Mon, 13 Feb 2023 13:20: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: Mon, 13 Feb 2023 18:20: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.167631235911103 (code B ref 61302); Mon, 13 Feb 2023 18:20:02 +0000 Original-Received: (at 61302) by debbugs.gnu.org; 13 Feb 2023 18:19:19 +0000 Original-Received: from localhost ([127.0.0.1]:51533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRdQ7-0002t1-2D for submit@debbugs.gnu.org; Mon, 13 Feb 2023 13:19:19 -0500 Original-Received: from mail-4018.proton.ch ([185.70.40.18]:30153) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRdQ5-0002sm-2J for 61302@debbugs.gnu.org; Mon, 13 Feb 2023 13:19:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjt.dev; s=protonmail2; t=1676312350; x=1676571550; bh=izUPVcra3Q5c+SgWusuL6I9GjE7kIhbAkK5SMn0DC8s=; 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=KR4bWEW4Dc7FAuxSxlv5OGfKfvId+FWv2YSAOO+5Oyh8qU08+4riyX2CauxsBjl4w IrOaeql6AnJTa67d9enovNFSZbwl/94VO8RVK4pB5X14Q85Z8l7iP1AuGYxFQKIZ2g PcTxNcT8P2bgnfS1sohsAVvXGiqnlv4DudFB6lUJ6AvFZ8Fp36vQldMldh4nGpLWBU Xz+eXKh05s2EMuoDFGjI4AxEw8W/TT3qqhgsMPAmW+xjbFhauhikbdB4jpe9c35BwQ ZKa1E8/aiu9RaR/HnKCypMdzORI3+zzs+0jd4cywRwd8kOyb7v0YoiOd5cJeAhfIpt D5l5OfEpJ5h8w== In-Reply-To: <7392c27d-0d5b-e3e9-ccd0-3d4bf329986c@secure.kjonigsen.net> 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:255514 Archived-At: On Monday, February 13th, 2023 at 10:04, Jostein Kj=C3=B8nigsen wrote: >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. Fair enough. Personally, I wouldn't mind a simpler/less complete bug report= if it's clearly stated that one didn't have enough time to fully detail it= . That way I can at least try to fix it and if not, no harm, we just wait u= ntil the reporter has time to give more information. >> >> I have been comparing to rust-mode, both now and when I was making >> rust-ts-mode. >Ok. Sorry for missing it. My bad :) No worries, you didn't miss anything. The exchange between Dmitry and I was= simply that I was curious about how other editors and IDEs (especially one= s with tree-sitter support like neovim) are highlighting these things, henc= e why rust-mode was not brought up. >> >> 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! Thanks :). >> >> > rust-mode: consistently fontify annotations (notice they are missin= g 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? Sorry about that, I forgot to reply to that. Hopefully I didn't miss anythi= ng else in this reply! Yes, font-lock-preprocessor-face is more appropriate - I will include that = change when I post my next patch. > >> > 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... Yup, that seems to be the case. I did see your other report that was also m= acro-related, I just didn't have anything to add to it. Although whether or not the grammar is capable of anything more here I have= no idea. Like C/C++, whenever macros are involved, trouble arrives it seems. > >> >> > it seems to fontify all variables using font-lock-variable-name-fac= e 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. I don't see why we can't be consistent about it, but it's just that the var= iable and function features themselves are, to my understanding, meant to h= ighlight all of that stuff fully. Then, the assignment, definition, and wha= tever smaller features can be used for folks who want more specific and "qu= ieter" highlights. I never added those smaller ones into any of my modes be= cause I want my code looking like a wild disco. > >> >> > it does not seem to handle ::* imports properly? See line 9. The wa= y 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 did notice that macro-related stuff had issues, but that's because of par= ser limitations. Aside from macros, I think everything else is fontified fine and much bette= r than rust-mode (pending my patch fixing up imports). > >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? :) I just don't see why any of those issues should stop it from being included= in emacs-29 - none of them are showstoppers, and nothing is forcing people= to use rust-ts-mode. I expect lots of bug reports for all the ts modes once emacs-29 comes out := D. > >-- >Jostein