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

Previous Next

Full log

Message #34 received at 61302 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Randy Taylor <dev <at> rjt.dev>, Jostein Kjønigsen
 <jostein <at> kjonigsen.net>
Cc: eliz <at> gnu.org, 61302 <at> debbugs.gnu.org
Subject: Re: bug#61302: 29.0.60; rust-ts-mode does not show
 function-invocation on field-properties
Date: Mon, 6 Feb 2023 04:45:37 +0200

On 06/02/2023 03:50, Randy Taylor wrote:
> 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?
> 
> When I introduced font-lock-property-face, I intended for it to be used 
> to highlight all properties.
> 
> Clearly that's not what most people had in mind, and it seems that many 
> would prefer property functions (for lack of better term) be highlighted 
> as functions.
> I can live with that, and yes, all the modes should be consistent so 
> Rust, Go, C/C++ and any anything else should be fixed up to abide.
> I'll fix Go up sometime next week unless someone beats me to it.

We're getting very close to when the pretest should be cut, I'm not sure 
if we have an extra week. We're probably pushing the limits of the 
feature freeze here already.

I've pushed a fix for Go as well, it looked very similar to Rust's one.

Curiously, in both cases the 'function' feature already contained the 
necessary rule (which matched only "property functions"), which then was 
later overridden by a rule in 'property' feature.

> Perhaps in the future we can introduce more fine-grained options for 
> properties if it's desired.

Sure, in case you or others really feel that need. There are several 
ways we could go about adding that capability.

In the meantime, I've also added highlighting of variable declarations 
to go-ts-mode (to 'definition', so it's on feature level 3). This should 
finish bringing rust and go ts modes to parity with the rest.

Please take it for a spin when you have the time. I'm not too familiar 
with Go, so I could have missed some cases. But hopefully not.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.