Subject: bug#61302: 29.0.60; rust-ts-mode does not show function-invocation on field-properties

From: Randy Taylor <[email-masked]>
Date: Mon, 13 Feb 2023 14:39:05 +0000

On Monday, February 13th, 2023 at 05:17, Jostein Kjønigsen <[email-masked]> wrote:
>Hey everyone.
>
>When I was filing the initial bug-report, I sort of noticed how rust-ts-mode was ... lets say not as consistent or refined about things as the other -ts-modes have turned out to be, but for the time being I decided to focus on functions-calls only, because that seemed to be the biggest omission. That said, I did notice other parts had room for improvement too.

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...

>
>No need for me to file a bug-report for that now though, as I see you two have done some very thorough work in the meantime :D
>
>If I were to complain about only -1- thing in that previous effort, it would be that you've compared rust-ts-mode to GitHub, VSCode, IntelliJ and what not ... but not rust-mode from MELPA! I think lots of the rust-ts-mode users will be coming from that major-mode, rather than other editors, so IMO it's quite a handy reference for how people might expect things to be.

I have been comparing to rust-mode, both now and when I was making rust-ts-mode.

>
>Below is a screenshot which puts rust-ts-mode (with the latest patches from this thread) head to head against rust-mode from MELPA:

Thanks. I wish you also would've included the code as text so I didn't have to type it all out :).

>
>From what I can tell, neither of them is perfect yet, but they both get some things right:
>
> rust-ts-mode: function invocations :)
> rust-ts-mode handles constants better (also escape-sequences, but not seen in this sample)
> 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).
> rust-mode: is able to handle nested macro-invocations. See line 42 and 44 above. From what I can tell, this seems to be due to a short-coming in the tree-sitter grammar for rust, and we may be able to fix it upstream, instead of monkey-patch things based on regexp's in rust-ts-mode
>
>As for things which are less great in rust-ts-mode:
>
> 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.

> 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).

> 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.

> 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.

>
>With utmost respect for all the work put in so far (rust is a complicated language after all), and I realize this is subjective, to me rust-ts-mode does not yet seem quite there, in terms of correctness or consistency. And as I'm sure Eli will remind us, Emacs 29 release is getting very, very, very close.
>
>Could it be an option to not have rust-ts-mode as part of Emacs 29, but leave it in git master for now? That would leave us time to sort out all these things properly, and also have good time to decide the things which actually needs to be agreed upon, before implementing the final fixes?

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).

>Just my 2 cents.
>-->Jostein