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.
next prev parent 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).