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, 29 Jun 2024 02:37:45 +0000 Message-ID: References: <36fGsZdSJ-V_6XVD6SuMoXHJKJ3e5x6xytnwwi2VJ0zzfcRRgOnY2FnWmCLfz4hifa1fkoMw0xCv4glCe8MZkoMqsUxsaY2N8LA1avOeaQk=@rjt.dev> <32ead709-88d3-4a96-b224-bc29aee3ae86@gutov.dev> <8D23DC8F-AC1A-4A33-8AC3-9583B9FC11AE@gmail.com> 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="28014"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , Stefan Kangas , 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 Jun 29 04:38:45 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 1sNNzB-00071O-5Q for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Jun 2024 04:38:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sNNyX-0007gn-Mw; Fri, 28 Jun 2024 22:38:05 -0400 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 1sNNyV-0007cP-1v for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2024 22:38:04 -0400 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 1sNNyU-0002JD-Pl for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2024 22:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sNNyU-000706-03 for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2024 22:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Randy Taylor Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Jun 2024 02:38:01 +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.171962868026902 (code B ref 69625); Sat, 29 Jun 2024 02:38:01 +0000 Original-Received: (at 69625) by debbugs.gnu.org; 29 Jun 2024 02:38:00 +0000 Original-Received: from localhost ([127.0.0.1]:36517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sNNyR-0006zo-GG for submit@debbugs.gnu.org; Fri, 28 Jun 2024 22:37:59 -0400 Original-Received: from mail-4323.proton.ch ([185.70.43.23]:19715) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sNNyP-0006zZ-5m for 69625@debbugs.gnu.org; Fri, 28 Jun 2024 22:37:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjt.dev; s=protonmail2; t=1719628670; x=1719887870; bh=cvXRiyQk06YNVE5C1WQp8yu74BCi2qpUm2R9xeh/TWo=; 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=IafsvkEjyh0HVbmRnfm2khlvDbZhv2PAG+IT3T4LPU75uldGD+bc2CnQLWQ2ZP9iR DpaUzamOqPsY1v9ayBiZTfOUGnbcI1N8ujA8scxrBeIVs+7SaNcfEVBeJUJj1XhSRt KzEkkBVROQBgaQM3IyyjO3DfNyN7P56BSDQIyF5utA8aEgxVlFdNaSGw9We78+QjE6 cWq07LUPXftCa6wqzLQQiGDl3PlmXHcsDpee4S5tOlhufjS33yMatKpgDVEyfupiqU z3ThdsaAeTRVZvAcK10nx2uKwIYGKSA/PL97mx3aGhpbWrYlRQ79bZIu/u8iQCM0XU RW7JiCHQlnX4A== In-Reply-To: <8D23DC8F-AC1A-4A33-8AC3-9583B9FC11AE@gmail.com> Feedback-ID: 44397038:user:proton X-Pm-Message-ID: f9731bc393a449a8d774664030416ebab1dc0a79 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:288088 Archived-At: On Friday, June 28th, 2024 at 00:43, Yuan Fu wrote: >=20 > > On Jun 27, 2024, at 7:40=E2=80=AFPM, Randy Taylor dev@rjt.dev wrote: > >=20 > > On Saturday, June 22nd, 2024 at 19:17, Yuan Fu casouri@gmail.com wrote: > >=20 > > > > On Jun 22, 2024, at 4:07=E2=80=AFAM, Stefan Kangas stefankangas@gma= il.com wrote: > > > >=20 > > > > Yuan Fu casouri@gmail.com writes: > > > >=20 > > > > > > On Mar 14, 2024, at 6:52 PM, Dmitry Gutov dmitry@gutov.dev wrot= e: > > > > > >=20 > > > > > > On 09/03/2024 05:50, Randy Taylor wrote: > > > > > >=20 > > > > > > > VariantA gets highlighted as a type and not a function at lev= el 3 because that > > > > > > > level doesn't support functions, but does support types. Mayb= e that could be > > > > > > > considered a bug in that it shouldn't be highlighted at all f= or level 3? > > > > > >=20 > > > > > > Probably. > > > > > >=20 > > > > > > > I'm not sure how worth it would be to do something about that= though, or how > > > > > > > easy. > > > > > >=20 > > > > > > Same. I haven't looked into it. > > > > > >=20 > > > > > > > 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 assu= ming a capitalized > > > > > > > identifier is a type, and I don't think that's something we c= an assume. People > > > > > > > can have capitalized functions and variables even if that goe= s against Rust's > > > > > > > usual style. Perhaps as a compromise we could introduce a var= iable (or something) > > > > > > > that lets the user specify that all capitalized identifiers s= hould be treated as > > > > > > > types? Maybe it even makes sense to default it to that behavi= our since I believe > > > > > > > most Rust code follows that style. > > > > > >=20 > > > > > > We do have some rules already that are based off whether an ide= ntifier is capitalized. I.e. some for use_as_clause, and another for highli= ghting an identifier with font-lock-constant-face if it's ALL_CAPS. So it m= ight be logical to carry on with that approach. > > > > > >=20 > > > > > > If the style is consistent enough across the ecosystem, of cour= se. > > > > > >=20 > > > > > > We could add a variable too, but that'd make the rules more com= plex so it would be helpful to understand first whether there are users who= would benefit. > > > > >=20 > > > > > For some reason I couldn=E2=80=99t see Randy=E2=80=99s messages. = So sorry if I missed anything. I suggest we go ahead with guessing and add = the variable if enough people complain. Personally speaking I believe the v= ast majority of Rust community wouldn=E2=80=99t write Rust code with capita= lized variable and non-capitalized types. The Rust community is very much i= nclined to the standard style, AFAICT. > > > >=20 > > > > Yuan, did you make any progress here? > > >=20 > > > From what I can tell Randy isn=E2=80=99t very convince of this idea, = so I didn=E2=80=99t make any changes. Randy, should we keep the status quo = and close this or should we explore something else? > > >=20 > > > Yuan > >=20 > > Sorry for the late response. > >=20 > > I thought we were waiting to see if enough people complain, and AFAIK n= o one else has. > > Perhaps I misinterpreted your message and > > you meant we should go ahead with adding this and only add the > > variable to control it if people complain - apologies if so. >=20 >=20 > That=E2=80=99s what I proposed, yeah. You didn=E2=80=99t say =E2=80=9Clet= =E2=80=99s do this=E2=80=9D (maybe I missed it, apologies if I did), so obv= iously I didn=E2=80=99t want to jump the gun ;-) >=20 > > I'm not opposed to the idea - it's the best we can do with what > > we've got. The only thing I am undecided on is if we want to bother > > with the variable to control it. If we did add it, it should be > > on by default since, as you mentioned, the vast majority of Rust > > code follows the same convention, and at that point who is actually > > going to turn it off? So it's probably not worth the hassle... > >=20 > > Were you thinking of adding this to the type feature or its own > > feature? >=20 >=20 > I was thinking adding this to the type feature. IMHO config options shoul= d be implemented by variables, not by splitting stuff into separate tree-si= tter font-lock features. I admit the name =E2=80=9Cfeature=E2=80=9D is a bi= t misleading in this regard... >=20 > Yuan Sounds good, we can consider an option if anyone complains. This is for master, right?