From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Randy Taylor Newsgroups: gmane.emacs.bugs Subject: bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum Date: Sat, 09 Mar 2024 03:50:38 +0000 Message-ID: <36fGsZdSJ-V_6XVD6SuMoXHJKJ3e5x6xytnwwi2VJ0zzfcRRgOnY2FnWmCLfz4hifa1fkoMw0xCv4glCe8MZkoMqsUxsaY2N8LA1avOeaQk=@rjt.dev> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19421"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , 69625@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 09 04:52:02 2024 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 1rinkf-0004nc-NP for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 09 Mar 2024 04:52:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rinkB-0004Qa-CK; Fri, 08 Mar 2024 22:51:31 -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 1rinkA-0004Pi-EC for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 22:51:30 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rinkA-0004jz-6O for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 22:51:30 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rinkg-0003n9-Ir for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2024 22:52:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Randy Taylor Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Mar 2024 03:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69625 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 69625-submit@debbugs.gnu.org id=B69625.170995628814531 (code B ref 69625); Sat, 09 Mar 2024 03:52:02 +0000 Original-Received: (at 69625) by debbugs.gnu.org; 9 Mar 2024 03:51:28 +0000 Original-Received: from localhost ([127.0.0.1]:60164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rink7-0003mJ-Vn for submit@debbugs.gnu.org; Fri, 08 Mar 2024 22:51:28 -0500 Original-Received: from mail-4317.proton.ch ([185.70.43.17]:18963) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rink5-0003m4-3r for 69625@debbugs.gnu.org; Fri, 08 Mar 2024 22:51:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjt.dev; s=protonmail; t=1709956245; x=1710215445; bh=e67QKpJRvE6ZSXEts+GZOw0G3EqLkLeL5NmcM6RNhek=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=i94ujihql5InhKwIK0xN55HN3z2Xz9y4QC9TbZPDQonVeio3wG/aiXF7+o2Chhkzk ANUDZmbMF9GU3oZlG7GrdivIJwry7Vm0eZNNFwvJBLzQIoOsiHiDqPFU/cqkH0xBWo My4P+yrK7+rOPTFjsIWTHYECGw3ZyglcxgmivmReAZBB87bnLmcJGZ7Yi8XzagvJzT EyMy4NtJHBAfPhoyswHWW/rhOGi4gNga1pLWYrw54heds4dMkxSE4ZnrsmmvaREEhx HjW/WkPfhh60p4rJuAWPMkVo6ZlpTw0h8AaQEEj8JIzURYQV3zy0NgWl/8dCV53ICU 4NNT6cmj+lzgg== In-Reply-To: Feedback-ID: 44397038:user:proton 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:281288 Archived-At: On Thursday, March 7th, 2024 at 23:43, Yuan Fu wrote: >=20 > X-Debug-CC: dev@rjt.dev mailto:dev@rjt.dev Should be X-Debbugs-CC ;). >=20 >=20 > (I lied a little bit about on the [PATCH] part: I have a solution but did= n=E2=80=99t turn it into a patch yet.) >=20 > The problem is follows: given the rust code below, some enum are not font= ified with type face under font lock level 3, and those enum are fontified = as function or variable under font lock level 4. >=20 > fn main() { > func(MyEnum::VariantA(0)); > func(MyEnum::VariantB); > func(VariantC); > func(VariantD(0)); > } >=20 > VariantA and VariantB are fontified correctly, but VariantC and VariantD = are not. >=20 > I think a simple rule that fontifies every capitalized identifier would f= ix this. But I don=E2=80=99t know if that=E2=80=99ll create other problem. = AFAIK capitalized identifier is always some type in rust, right? >=20 For VariantA and VariantD, these are constructors being used as functions, so I think they are technically being highlighted correctly at level 4. Whether or not that is desired is another question - I think that is simply a matter of opinion/preference. VariantA gets highlighted as a type and not a function at level 3 because t= hat level doesn't support functions, but does support types. Maybe that could b= e considered a bug in that it shouldn't be highlighted at all for level 3? I'm not sure how worth it would be to do something about that though, or ho= w easy. For VariantC, our (and tree-sitter's) best guess is that it's a variable. We can't really know it's a type without guessing - like assuming a capital= ized identifier is a type, and I don't think that's something we can assume. Peo= ple can have capitalized functions and variables even if that goes against Rust= 's usual style. Perhaps as a compromise we could introduce a variable (or some= thing) that lets the user specify that all capitalized identifiers should be treat= ed as types? Maybe it even makes sense to default it to that behaviour since I be= lieve most Rust code follows that style. I don't really think this is a tree-sitter problem to solve but more so an = LSP one: tree-sitter can't know that all of these are enums based on how they are us= ed. As was mentioned in that GitHub thread, LSP with semantic tokens is the way= to go for the most accuracy. But even with semantic tokens, how to highlight enum= variants being used as functions comes down to opinion methinks. > This is first reported on rust-mode=E2=80=99s GitHub repo: https://github= .com/rust-lang/rust-mode/issues/518 >=20 > Yuan