unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: "Randy Taylor" <dev@rjt.dev>,
	"Jostein Kjønigsen" <jostein@kjonigsen.net>
Cc: eliz@gnu.org, 61302@debbugs.gnu.org
Subject: 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	[thread overview]
Message-ID: <3e40d23f-1629-c5b7-1f17-d769790d6494@yandex.ru> (raw)
In-Reply-To: <DXi93z-_FKBIozv2jpLLEcvU09NP_AIHfOtZXc3-y_MwghIXv7DElwB7Hh6-YFz0sW6XkmHKv5OYd0uburK5y2CMsxyk-PcVcmevqr2l9ww=@rjt.dev>

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.





  reply	other threads:[~2023-02-06  2:45 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-05 20:15 bug#61302: 29.0.60; rust-ts-mode does not show function-invocation on field-properties Jostein Kjønigsen
2023-02-05 21:30 ` Randy Taylor
2023-02-05 21:52   ` Jostein Kjønigsen
2023-02-05 21:59     ` Jostein Kjønigsen
2023-02-06  1:50       ` Randy Taylor
2023-02-06  2:45         ` Dmitry Gutov [this message]
2023-02-06  2:57           ` Randy Taylor
2023-02-07 14:26           ` Randy Taylor
2023-02-07 18:16             ` Dmitry Gutov
2023-02-07 18:25               ` Dmitry Gutov
2023-02-08  3:38                 ` Randy Taylor
2023-02-08 15:44                   ` Dmitry Gutov
2023-02-09  3:38                     ` Randy Taylor
2023-02-09 21:19                       ` Dmitry Gutov
2023-02-10  3:44                         ` Randy Taylor
     [not found]                           ` <33cec9a6-7e69-2eb3-a8a6-58ce23a5c185@yandex.ru>
2023-02-12  2:48                             ` Randy Taylor
2023-02-13  3:37                               ` Dmitry Gutov
2023-02-14  3:25                                 ` Randy Taylor
2023-02-14 11:42                                   ` Jostein Kjønigsen
2023-02-14 12:39                                     ` Randy Taylor
2023-02-14 14:28                                       ` Jostein Kjønigsen
2023-02-14 22:14                                       ` Dmitry Gutov
2023-02-15  2:07                                         ` Randy Taylor
2023-02-16  1:53                                           ` Dmitry Gutov
2023-02-18  3:27                                             ` Dmitry Gutov
2023-02-18 20:42                                               ` Randy Taylor
2023-02-18 21:45                                                 ` Dmitry Gutov
2023-02-18 23:31                                                   ` Randy Taylor
2023-02-19  0:13                                                     ` Dmitry Gutov
2023-02-19  0:50                                                       ` Randy Taylor
2023-02-19 17:23                                                         ` Dmitry Gutov
2023-02-18 20:59                                               ` Dmitry Gutov
2023-02-13 10:17                           ` Jostein Kjønigsen
2023-02-13 14:39                             ` Randy Taylor
2023-02-13 15:04                               ` Jostein Kjønigsen
2023-02-13 18:19                                 ` Randy Taylor
2023-02-13 19:57                               ` Dmitry Gutov
2023-02-13 20:49                                 ` Dmitry Gutov
2023-02-13 19:59                             ` Dmitry Gutov
2023-02-05 21:56   ` Dmitry Gutov
2023-02-06  2:06     ` Randy Taylor
2023-02-06  2:16       ` Dmitry Gutov
2023-02-05 21:44 ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3e40d23f-1629-c5b7-1f17-d769790d6494@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=61302@debbugs.gnu.org \
    --cc=dev@rjt.dev \
    --cc=eliz@gnu.org \
    --cc=jostein@kjonigsen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).