From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum Date: Thu, 27 Jun 2024 21:43:51 -0700 Message-ID: <8D23DC8F-AC1A-4A33-8AC3-9583B9FC11AE@gmail.com> References: <36fGsZdSJ-V_6XVD6SuMoXHJKJ3e5x6xytnwwi2VJ0zzfcRRgOnY2FnWmCLfz4hifa1fkoMw0xCv4glCe8MZkoMqsUxsaY2N8LA1avOeaQk=@rjt.dev> <32ead709-88d3-4a96-b224-bc29aee3ae86@gutov.dev> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) 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="30396"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , Stefan Kangas , 69625@debbugs.gnu.org To: Randy Taylor Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 28 07:54:25 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 1sN4Yy-0007jh-RF for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 28 Jun 2024 07:54:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sN4Yf-0000b0-5G; Fri, 28 Jun 2024 01:54: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 1sN4Yd-0000ai-SJ for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2024 01:54:03 -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 1sN4Yd-0002kr-KE for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2024 01:54:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sN4Yc-0000Ul-8C for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2024 01:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Jun 2024 05:54: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.17195540011843 (code B ref 69625); Fri, 28 Jun 2024 05:54:02 +0000 Original-Received: (at 69625) by debbugs.gnu.org; 28 Jun 2024 05:53:21 +0000 Original-Received: from localhost ([127.0.0.1]:51383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sN4Xx-0000Tf-1o for submit@debbugs.gnu.org; Fri, 28 Jun 2024 01:53:21 -0400 Original-Received: from mail-yw1-f180.google.com ([209.85.128.180]:58401) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sN4Xu-0000TR-Kt for 69625@debbugs.gnu.org; Fri, 28 Jun 2024 01:53:19 -0400 Original-Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-6480542003dso2099407b3.0 for <69625@debbugs.gnu.org>; Thu, 27 Jun 2024 22:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719553934; x=1720158734; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OC2nOoRYHf831xvZeyU6c0yZ0wQdeU4p7VpefIJnjY8=; b=IlYWDRAGcEVGq7DX2BcAtVMhUaymeZ0B+mkZDffs4oX4iUeFAm+Ojhb6bgOj7TqDvI CdkvPYLQEMSUHja4CO0XDzBoJZ0MRXYgkTFcm+wZ7u7X08boVRK7eAV0nV+ePcgqaVze a4FPWoLPryGSTTMjRXEzdTuGYQe6x1dJkEUhs1m7PshnhlD3/WCFnMWqJlVLVfPmRKL/ JOdDZjTuSLJsPBgkP6mdoIHXOZH4xMht6fMFGjlEhrwVnKN73wn4dXWDDVlP28W6+Dj8 I0RFGNsvftWpj7yhBGOyNH7JaYTZhCsrxe04F7cQFi+5nsprIm9oeuFkXm7urD2iNc50 qpTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719553934; x=1720158734; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OC2nOoRYHf831xvZeyU6c0yZ0wQdeU4p7VpefIJnjY8=; b=W9+tVy0HxGI6ayzWXXHQlq+rAGOgC25lm0Cy4GMsDJ2vHN+1TY26fCq5rUNmFumUeO ywDl2KAOePyxGI0cdiOwsABTnpUAnr5nFLcFN979EOwGCOFTdFic63tbBKGOISpXCVWK l2OVLNQCooq18Uf4IkfKJWlbmr/MANe8zarxVrAPs/XtieWGYK6toiO8sp2TSZja3E1X gozoOU3Ki60+Os7GEzehHD8i11jbVtLj7QDfIrD+b0JaCX/Xs+A/GOE9R6d/rnXy3Q/8 NQkn04j0XhV2FZuRHlmZJSJVs1SqKDRn90sL1A6o2u7GsGZ1GZzZzVvqGH4todQqFOry TUIQ== X-Forwarded-Encrypted: i=1; AJvYcCU8BjqIayEqFXFKRK9rmGUL4MQFgQtkYqYkck4GTqIgRrokaZ7mS7748A89aVl+GA1Edrlf4UCCVBcbEtHsAV8wg7PF0iQ= X-Gm-Message-State: AOJu0YxAJvhKIAFddpQ/r+TA7/FrLuSCpU689cKyFfv+5fnZX7ri3V+q mRs9ybjQMOwyWCcGQN/rzSJfjIjeF5Pupn3OQ6SPaTVT1k9la5hozHkCciGD X-Google-Smtp-Source: AGHT+IFk/HGFQjQsaiCrf2RR07vmyomn9KWMlj8HYXGkMmHq30Jz2b0/lJiQpIJYoHU61wHItz6X3Q== X-Received: by 2002:a05:6a20:6a1d:b0:1bd:1d15:f089 with SMTP id adf61e73a8af0-1bd1d15f1cbmr14303937637.54.1719549842988; Thu, 27 Jun 2024 21:44:02 -0700 (PDT) Original-Received: from smtpclient.apple ([2601:646:8f81:6120:905e:641:dacc:2f83]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fac10d1c83sm6186295ad.17.2024.06.27.21.44.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jun 2024 21:44:02 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3774.600.62) 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:288044 Archived-At: > On Jun 27, 2024, at 7:40=E2=80=AFPM, Randy Taylor wrote: >=20 > 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.com 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 = that could be >>>>>> considered a bug in that it shouldn't be highlighted at all for = 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 assuming = a capitalized >>>>>> 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 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 = identifier is 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 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 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 vast majority of Rust community wouldn=E2=80=99t write Rust code = with capitalized variable and non-capitalized types. The Rust community = is very much inclined to the standard style, AFAICT. >>>=20 >>> Yuan, did you make any progress here? >>=20 >>=20 >> =46rom 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 = no 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. 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 = obviously 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? I was thinking adding this to the type feature. IMHO config options = should be implemented by variables, not by splitting stuff into separate = tree-sitter font-lock features. I admit the name =E2=80=9Cfeature=E2=80=9D= is a bit misleading in this regard... Yuan