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

["Jostein Kjønigsen" <jostein@kjonigsen.net>]

[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]



--
Vennlig hilsen
Jostein Kjønigsen

jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjønigsen.no <https://jostein.xn--kjnigsen-64a.no/>

On Sun, Feb 5, 2023, at 22:52, Jostein Kjønigsen wrote:
> 
> On Sun, Feb 5, 2023, at 22:30, Randy Taylor wrote:
>> 
>> That's expected (at least to me) because it's a property. The same applies to c-ts-mode and go-ts-mode as well.
>> 
> I mean… yea it’s a property, but it’s clearly a function-valued property, and you’re calling it. 
> 
> Even simpler: If you store a function reference in a plain variable and call that variable, is that a variable or a function you’re calling? ;)
> 
> As for consistency, csharp-ts-mode, js-ts-mode, typescript-ts-mode (and tsx-ts-mode) all does the  exact opposite: functions always takes precedence over properties.
> 
> In fact, they mostly highlight declarations of properties only, not regular access, which kind avoids the duality-problem we’re seeing in rust-ts-mode in this particular case. 
> 
> Would it be an option/goal to try to align these other modes with a such a model which is somewhat more clearly defined to make it simpler  to resolve cases like this?
> 
> —
> Jostein

Also worth noting, there are clearly highly tailored treesitter-queries to fontify these exact property-access based function-invocations. They are not getting fontified by luck or wide/general matchers elsewhere. 

Someone somewhere wanted these to be fontified, and had patches accepted for that exact purpose. 

To say that it is expected for them not to be used would then imply the queries should not be there in the first place. 

I’m not saying which side is right, but if we are to chose one, we should strive to do so consistently :) 

—
Jostein

[-- Attachment #2: Type: text/html, Size: 2962 bytes --]