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: Fri, 28 Jun 2024 02:40:49 +0000 Message-ID: References: <36fGsZdSJ-V_6XVD6SuMoXHJKJ3e5x6xytnwwi2VJ0zzfcRRgOnY2FnWmCLfz4hifa1fkoMw0xCv4glCe8MZkoMqsUxsaY2N8LA1avOeaQk=@rjt.dev> <32ead709-88d3-4a96-b224-bc29aee3ae86@gutov.dev> 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="36408"; 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 Fri Jun 28 08:18:17 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 1sN4w5-0009FB-3Y for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 28 Jun 2024 08:18:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sN4vt-0007dI-5N; Fri, 28 Jun 2024 02:18: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 1sN4vs-0007cb-18 for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2024 02:18: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 1sN4vr-0001Bk-PV for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2024 02:18:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sN4vq-0001Em-Dq for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2024 02:18: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: Fri, 28 Jun 2024 06:18: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.17195554304699 (code B ref 69625); Fri, 28 Jun 2024 06:18:02 +0000 Original-Received: (at 69625) by debbugs.gnu.org; 28 Jun 2024 06:17:10 +0000 Original-Received: from localhost ([127.0.0.1]:51629 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sN4v0-0001Di-8w for submit@debbugs.gnu.org; Fri, 28 Jun 2024 02:17:10 -0400 Original-Received: from mail-41103.protonmail.ch ([185.70.41.103]:34143) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sN4uw-0001D9-6W for 69625@debbugs.gnu.org; Fri, 28 Jun 2024 02:17:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rjt.dev; s=protonmail2; t=1719542453; x=1719801653; bh=iYq7sMV5fox+fUnfLJoUQh+GodzYfoXsX5+ACSz/fGE=; 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=twH8TDRwpVpHQTUSdmCed/cO6f0aE5YEA0m/EGHKZAKdMt1O6/LnkFj6K90oY//P9 wJX5m88K7YDpoIa+ia0gQvkoQjBCXMgQebREEAxc4mZIkxtYjESmlLGZndbFnjX11W TNTpndIAI56+/+H7auB52FZW4EgGkdWMt6tAQ6gKjKTTC5JQ8cZsGZBeW6xqUmyncA OALgQnFolUL8/uqnEZf5xQFUBSiIfJfYwCNJyuMTcBDL2vTsZkoGA1JgzILs5Zms3P FtpEydJGd6mYfadhZ7PjxC53Xt1GR8V5grFUTb3W6juQ1fnHa4ObjEH1gg7Y1pgIUx vFUkgzgbqQq1w== In-Reply-To: Feedback-ID: 44397038:user:proton X-Pm-Message-ID: e2e2c5b5fe38e15e4b6505571d840aa17a8e1263 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:288053 Archived-At: On Saturday, June 22nd, 2024 at 19:17, Yuan Fu wrote: >=20 >=20 >=20 >=20 > > On Jun 22, 2024, at 4:07=E2=80=AFAM, Stefan Kangas stefankangas@gmail.c= om wrote: > >=20 > > Yuan Fu casouri@gmail.com writes: > >=20 > > > > On Mar 14, 2024, at 6:52 PM, Dmitry Gutov dmitry@gutov.dev wrote: > > > >=20 > > > > On 09/03/2024 05:50, Randy Taylor wrote: > > > >=20 > > > > > VariantA gets highlighted as a type and not a function at level 3= because that > > > > > level doesn't support functions, but does support types. Maybe th= at could be > > > > > considered a bug in that it shouldn't be highlighted at all for l= evel 3? > > > >=20 > > > > Probably. > > > >=20 > > > > > I'm not sure how worth it would be to do something about that tho= ugh, 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 v= ariable. > > > > > We can't really know it's a type without guessing - like assuming= a capitalized > > > > > identifier is a type, and I don't think that's something we can a= ssume. People > > > > > can have capitalized functions and variables even if that goes ag= ainst Rust's > > > > > usual style. Perhaps as a compromise we could introduce a variabl= e (or something) > > > > > that lets the user specify that all capitalized identifiers shoul= d be treated as > > > > > types? Maybe it even makes sense to default it to that behaviour = since I believe > > > > > most Rust code follows that style. > > > >=20 > > > > We do have some rules already that are based off whether an identif= ier is capitalized. I.e. some for use_as_clause, and another for highlighti= ng an identifier with font-lock-constant-face if it's ALL_CAPS. So it might= be logical to carry on with that approach. > > > >=20 > > > > If the style is consistent enough across the ecosystem, of course. > > > >=20 > > > > We could add a variable too, but that'd make the rules more complex= so it would be helpful to understand first whether there are users who wou= ld benefit. > > >=20 > > > For some reason I couldn=E2=80=99t see Randy=E2=80=99s messages. So s= orry if I missed anything. I suggest we go ahead with guessing and add the = variable if enough people complain. Personally speaking I believe the vast = majority of Rust community wouldn=E2=80=99t write Rust code with capitalize= d variable and non-capitalized types. The Rust community is very much incli= ned to the standard style, AFAICT. > >=20 > > Yuan, did you make any progress here? >=20 >=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 Sorry for the late response. I thought we were waiting to see if enough people complain, and AFAIK no on= e 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. 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... Were you thinking of adding this to the type feature or its own feature?