From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jostein =?UTF-8?Q?Kj=C3=B8nigsen?= Newsgroups: gmane.emacs.bugs Subject: bug#59897: 29.0.60; csharp-ts-mode: variable-name fontified as method when invoking method with generic type-argument. Date: Thu, 8 Dec 2022 12:31:54 +0100 Message-ID: <667add54-91b3-f820-3163-0f33d9d97056@secure.kjonigsen.net> References: <76edd79f-6da1-4c28-b20e-5eb4d9a819b2@app.fastmail.com> <87zgby9pax.fsf@thornhill.no> <8fdc4d5d-17ac-3a06-d602-637df9fe1be1@secure.kjonigsen.net> <87r0xa9mjy.fsf@thornhill.no> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------PQTzMZChn4GgAa5H0vzI5B0i" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35164"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: casouri@gmail.com, 59897@debbugs.gnu.org To: Theodor Thornhill , Jostein =?UTF-8?Q?Kj=C3=B8nigsen?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 08 12:33:26 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p3F9Y-0008tf-Ol for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 08 Dec 2022 12:33:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p3F9G-0004MZ-Nv; Thu, 08 Dec 2022 06:33:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p3F9C-0004M4-Hb for bug-gnu-emacs@gnu.org; Thu, 08 Dec 2022 06:33:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p3F9C-0002ps-7m for bug-gnu-emacs@gnu.org; Thu, 08 Dec 2022 06:33:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p3F9B-000391-KC for bug-gnu-emacs@gnu.org; Thu, 08 Dec 2022 06:33:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jostein =?UTF-8?Q?Kj=C3=B8nigsen?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Dec 2022 11:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59897 X-GNU-PR-Package: emacs Original-Received: via spool by 59897-submit@debbugs.gnu.org id=B59897.167049912712079 (code B ref 59897); Thu, 08 Dec 2022 11:33:01 +0000 Original-Received: (at 59897) by debbugs.gnu.org; 8 Dec 2022 11:32:07 +0000 Original-Received: from localhost ([127.0.0.1]:56202 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3F8I-00038l-Hr for submit@debbugs.gnu.org; Thu, 08 Dec 2022 06:32:07 -0500 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]:46899) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3F8E-00038O-Lo for 59897@debbugs.gnu.org; Thu, 08 Dec 2022 06:32:05 -0500 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 20A225C00D2; Thu, 8 Dec 2022 06:31:57 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 08 Dec 2022 06:31:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= secure.kjonigsen.net; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1670499117; x= 1670585517; bh=M1Uv9Kt9r2zsPwuklYM1xmjtgXXMbR5/T6vGZGj5Mhg=; b=c 7t1t3riUL+FibBa7or0y/Ja4GnaWF1GZNVzgMWTKaFv7+iNLz61t+XivTep4qwRl +kPHZcwgWJcqs4LzH1heSnylyzANbgSZeuh9bM2sb74w+AGtVh3bfL94f7P2kKjG xnDvwmChCo0JMRqe8nD+3srOjMWY7i4p6x4yiobRS7JQf8r88VV9w8EDtnDyEqUV kMO//fjZHX3TJ07VzW/4MpJD6EKVI0NC5rXwZAite/OdRNvHkB/bQhn+0IWreS8A CTVlCm3rCFkwI9fdlzOChbsS5wg6WfoxrPzteeFCoScNolrVjldMfYpfzDwIuph4 vjfDm8IvgH/vWM/7+uH7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1670499117; x=1670585517; bh=M1Uv9Kt9r2zsPwuklYM1xmjtgXXM bR5/T6vGZGj5Mhg=; b=AC/10iyUrCT+hhQEeJBnHyildDQxmmZjk8jahmzLRIJA RlomyLCulJEUqMvfOMh02j1WwktDC4QMGAN3IcGbUtSvTGC+2LG8qd0Vc5Zf5RTC m/y9oIOv/qCVsZhkAEi7Kt9hY/ieXwvHlCQ2v/1mqe9tlW14TOe1KkFDWGaa/gjz HBC/8IoIIrx1veH+fTdS7qhFMCSNAYcssbv1fz7Sv5H6hyv9y4Wz7L/f2bt4G4jD 8uMw8jyaFcftCsZ1FYv3KRIceQVF3Qxpp47rwhW5C1GP/4bofrnUuSLhwsXDKTD+ 1+U/zt5yi3vrSirTV4CLEtpOPbDcv5PXXKJ3a3DJqw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvddtgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtkfffgggfuffvvehfhfgjsegrtderredtfeejnecuhfhrohhmpeflohhsthgv ihhnucfmjhppnhhighhsvghnuceojhhoshhtvghinhesshgvtghurhgvrdhkjhhonhhigh hsvghnrdhnvghtqeenucggtffrrghtthgvrhhnpefggeduueefudfhleegjeffffelffeh ueduvdelheejueeigeeuieeftdfggfdugfenucffohhmrghinheprghsphdrnhgvthenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjohhsthgv ihhnsehsvggtuhhrvgdrkhhjohhnihhgshgvnhdrnhgvth X-ME-Proxy: Feedback-ID: ib2f84088:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 8 Dec 2022 06:31:56 -0500 (EST) Content-Language: en-US In-Reply-To: <87r0xa9mjy.fsf@thornhill.no> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:250275 Archived-At: This is a multi-part message in MIME format. --------------PQTzMZChn4GgAa5H0vzI5B0i Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 08.12.2022 12:12, Theodor Thornhill wrote: > Jostein Kjønigsen writes: > >> On 08.12.2022 11:12, Theodor Thornhill wrote: >>> Jostein Kjønigsen writes: >>> >>>> When I use the new csharp-ts-mode, method fontification is usually accurate with only 1 exception which I have >>>> encountered so far: >>>> >>>> When calling methods on objects, and that method accepts a generic type-argument. You typically see this in >>>> Startup.cs-like files in ASP.Net Core projects: >>>> >>>> services.AddSomeExtensionWithoutTypeArguments(); >>>> services.AddSomeExtensionWithTypeArguments(); >>>> >>>> In the above cases we see that fontification of "services" differs. >>>> >>>> For the first line, services is fontified using font-lock-variable-name-face (correct), but in the latter case services >>>> is fontified using font-lock-function-name-face (incorrect). >>>> >>>> In both cases I expected services to be fontified using font-lock-variable-name-face. >>>> >>> Can you test this patch, Jostein, and if you're happy, please install, >>> Yuan :-) >> I beat you by 3 minutes, but I'll be a gentleman and test none the less :D >> >> You test mine, and we can see which one we prefer? > Sure! Both seems to work from what I can tell :-) I'll let you be the > judge! > > Theo Your patch solves the issue described in the bug, but does not handle another fontification error I discovered while testing my patch: SimpleGenericMethod(params); In the above example SimpleGenericMethod is fontified using font-lock-type-face instead of font-lock-function-name-face. My patch fixes that case as well. As for which patch to choose: * From an objective perspective, the way I understand the code, your patch overrides an existing fontification to apply variable-name instead. * My patch however changes some selectors to be more specific selectors to avoid fontifying the variable-identifier, and also creates a new, highly-specific selector to fontify the variable-name aspect as well. From a performance perspective, I would assume the latter approach is more performant, but I don't know enough tree-sitter internals to say that with 100% confidence. Does anyone else know? -- Jostein --------------PQTzMZChn4GgAa5H0vzI5B0i Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 08.12.2022 12:12, Theodor Thornhill wrote:
Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:


On 08.12.2022 11:12, Theodor Thornhill wrote:

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:


When I use the new csharp-ts-mode, method fontification is usually accurate with only 1 exception which I have
encountered so far:

When calling methods on objects, and that method accepts a generic type-argument. You typically see this in
Startup.cs-like files in ASP.Net Core projects:

services.AddSomeExtensionWithoutTypeArguments();
services.AddSomeExtensionWithTypeArguments<MyType>();

In the above cases we see that fontification of "services" differs.

For the first line, services is fontified using font-lock-variable-name-face (correct), but in the latter case services
is fontified using font-lock-function-name-face (incorrect).

In both cases I expected services to be fontified using font-lock-variable-name-face.


Can you test this patch, Jostein, and if you're happy, please install,
Yuan :-)

I beat you by 3 minutes, but I'll be a gentleman and test none the less :D

You test mine, and we can see which one we prefer?

Sure!  Both seems to work from what I can tell :-)  I'll let you be the
judge!

Theo

Your patch solves the issue described in the bug, but does not handle another fontification error I discovered while testing my patch:

SimpleGenericMethod<Type>(params);

In the above example SimpleGenericMethod is fontified using font-lock-type-face instead of font-lock-function-name-face. My patch fixes that case as well.

As for which patch to choose:

  • From an objective perspective, the way I understand the code, your patch overrides an existing fontification to apply variable-name instead.
  • My patch however changes some selectors to be more specific selectors to avoid fontifying the variable-identifier, and also creates a new, highly-specific selector to fontify the variable-name aspect as well.

From a performance perspective, I would assume the latter approach is more performant, but I don't know enough tree-sitter internals to say that with 100% confidence.

Does anyone else know?

--
Jostein

--------------PQTzMZChn4GgAa5H0vzI5B0i--