From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum Date: Sat, 22 Jun 2024 04:07:07 -0700 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="9779"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Randy Taylor , 69625@debbugs.gnu.org To: Yuan Fu , Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 22 13:09:15 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 1sKycN-0002LW-GG for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Jun 2024 13:09:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sKycC-00038w-7A; Sat, 22 Jun 2024 07:09:04 -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 1sKycA-00038Q-4W for bug-gnu-emacs@gnu.org; Sat, 22 Jun 2024 07:09:02 -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 1sKyc9-0006IP-Sp for bug-gnu-emacs@gnu.org; Sat, 22 Jun 2024 07:09:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sKyc9-00041e-Je for bug-gnu-emacs@gnu.org; Sat, 22 Jun 2024 07:09:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Jun 2024 11:09: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.171905449615410 (code B ref 69625); Sat, 22 Jun 2024 11:09:01 +0000 Original-Received: (at 69625) by debbugs.gnu.org; 22 Jun 2024 11:08:16 +0000 Original-Received: from localhost ([127.0.0.1]:44558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKybQ-00040U-7k for submit@debbugs.gnu.org; Sat, 22 Jun 2024 07:08:16 -0400 Original-Received: from mail-ed1-f48.google.com ([209.85.208.48]:47369) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKybN-00040B-7V for 69625@debbugs.gnu.org; Sat, 22 Jun 2024 07:08:14 -0400 Original-Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-57d06101d76so2942786a12.3 for <69625@debbugs.gnu.org>; Sat, 22 Jun 2024 04:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719054428; x=1719659228; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=pOxQs/YybgkdpPZxutKIxcBIth/v0BoukLzTRSzTboc=; b=SVj0LgWj67nUTsb3xgEbRfzO6zQ2w3YSgypmbAu/40zec1/k0ZIKnmIgIjD84GDR4k reVxxGCQWCh+yyWMYqU1HumNQvRW4JYDA30U8uMm+aee509dQG7BJbRtW+Bd1niL8u56 14Qwvh0ZsqJs7YZ1mGTKen94ubZ/8DVWmFW0qR4pHPNPNYp9TBv4pjieYAVB56tXqZSj 0+Bdts//YsRwoofTnG643K0Pf5HJjah9MjKSROrX4dQo1wv3iuLNSnuDznZBT1bCLzG0 zq1NPfrlMCtHvhIdDVs2eCM0mviyCQuGxQ1svm7g+QWCtg5DBS9bJbtv481s+S0p8ImY fBWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719054428; x=1719659228; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=pOxQs/YybgkdpPZxutKIxcBIth/v0BoukLzTRSzTboc=; b=jSb5j+yLKeZVOkfUpUX9Hg1zYe8HPY7TGifjbv9GjLkRAp9mcCWkjYAttTlQnPd094 Q8d+cqXDofApThKhpO7Nh+klC6PA9JZIRtAGUboETWb077/ocPVp7wl8FUqZTLpVKflw ZsgxZEEeNrSiQIbluVuDdFV280gc1Rf8Co+z+dAhqPoHHqtstC9gpz69q7s6HjONiyTf zjrP1lpX7XdL85kCuhjMMGMSRYGQa1xiIH30ayz7Ge0KUj/L0gP+98POdACp+uFroMxA zFeLbMOm1pWhzV7hjzG03Fundigbu10Ax4jRrLs3ZGBdXQPFpsp0cP2G35lA9duidmCV wUtA== X-Forwarded-Encrypted: i=1; AJvYcCXLExYQhvhmRvEMuu4KEl4fVXAIa5+UmYCtHczCQ5KVD4FFApgHbJmUFpdsGvXIl3g20DsVfHsbQjo10zqgIFsFVfGbsA0= X-Gm-Message-State: AOJu0YzZHNLHABdFpX82zZC4UMb1UBHjiGtwmM7bBVANOKNY1OPSKOte 4mv3BYtDTky7WtxNELwaR9lsxyIgMH8c1PtBUtypIkyz84pQ8j4g5zKoSI965Uzpwd+KykNtFeu 5bLaJJBHO4npYnC0isV/zQH1VU/k= X-Google-Smtp-Source: AGHT+IGs9tk3fME6TR03z6r3JN5hFVaf/0OidiI4ULD0rEbQV+cNax3HydvlGFVvxfKCyEeZBpir/QRopVZ2f8gsJcs= X-Received: by 2002:a50:a693:0:b0:57c:68fd:2bc9 with SMTP id 4fb4d7f45d1cf-57d49c976d1mr149447a12.3.1719054427364; Sat, 22 Jun 2024 04:07:07 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 22 Jun 2024 04:07:07 -0700 In-Reply-To: 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:287693 Archived-At: Yuan Fu writes: >> On Mar 14, 2024, at 6:52 PM, Dmitry Gutov wrote: >> >> On 09/03/2024 05:50, Randy Taylor wrote: >>> VariantA gets highlighted as a type and not a function at level 3 becau= se that >>> level doesn't support functions, but does support types. Maybe that cou= ld be >>> considered a bug in that it shouldn't be highlighted at all for level 3= ? >> >> Probably. >> >>> I'm not sure how worth it would be to do something about that though, o= r how >>> easy. >> >> Same. I haven't looked into it. >> >>> For VariantC, our (and tree-sitter's) best guess is that it's a variabl= e. >>> We can't really know it's a type without guessing - like assuming a cap= italized >>> identifier is a type, and I don't think that's something we can assume.= People >>> 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 = something) >>> that lets the user specify that all capitalized identifiers should be t= reated as >>> types? Maybe it even makes sense to default it to that behaviour since = I believe >>> most Rust code follows that style. >> >> We do have some rules already that are based off whether an identifier i= s capitalized. I.e. some for use_as_clause, and another for highlighting an= identifier with font-lock-constant-face if it's ALL_CAPS. So it might be l= ogical to carry on with that approach. >> >> If the style is consistent enough across the ecosystem, of course. >> >> We could add a variable too, but that'd make the rules more complex so i= t would be helpful to understand first whether there are users who would be= nefit. > > 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 vari= able if enough people complain. Personally speaking I believe the vast majo= rity of Rust community wouldn=E2=80=99t write Rust code with capitalized va= riable and non-capitalized types. The Rust community is very much inclined = to the standard style, AFAICT. Yuan, did you make any progress here?