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

[Randy Taylor <dev@rjt.dev>]

On Monday, February 13th, 2023 at 10:04, Jostein Kjønigsen <jostein@secure.kjonigsen.net> 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 until 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 ones with tree-sitter support like neovim) are highlighting these things, hence 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 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?

Sorry about that, I forgot to reply to that. Hopefully I didn't miss anything 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 macro-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-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.

I don't see why we can't be consistent about it, but it's just that the variable and function features themselves are, to my understanding, meant to highlight all of that stuff fully. Then, the assignment, definition, and whatever smaller features can be used for folks who want more specific and "quieter" highlights. I never added those smaller ones into any of my modes because I want my code looking like a wild disco.

>
>>
>> >    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 did notice that macro-related stuff had issues, but that's because of parser limitations.
Aside from macros, I think everything else is fontified fine and much better 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