GNU bug report logs - #69625
30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum

Previous Next

Full log

View this message in rfc822 format

From: Randy Taylor <dev <at> rjt.dev>
To: Yuan Fu <casouri <at> gmail.com>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Stefan Kangas <stefankangas <at> gmail.com>, 69625 <at> debbugs.gnu.org
Subject: bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
Date: Sat, 29 Jun 2024 02:37:45 +0000

On Friday, June 28th, 2024 at 00:43, Yuan Fu <casouri <at> gmail.com> wrote:
> 
> > On Jun 27, 2024, at 7:40 PM, Randy Taylor dev <at> rjt.dev wrote:
> > 
> > On Saturday, June 22nd, 2024 at 19:17, Yuan Fu casouri <at> gmail.com wrote:
> > 
> > > > On Jun 22, 2024, at 4:07 AM, Stefan Kangas stefankangas <at> gmail.com wrote:
> > > > 
> > > > Yuan Fu casouri <at> gmail.com writes:
> > > > 
> > > > > > On Mar 14, 2024, at 6:52 PM, Dmitry Gutov dmitry <at> gutov.dev wrote:
> > > > > > 
> > > > > > On 09/03/2024 05:50, Randy Taylor wrote:
> > > > > > 
> > > > > > > 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?
> > > > > > 
> > > > > > Probably.
> > > > > > 
> > > > > > > I'm not sure how worth it would be to do something about that though, or how
> > > > > > > easy.
> > > > > > 
> > > > > > Same. I haven't looked into it.
> > > > > > 
> > > > > > > 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.
> > > > > > 
> > > > > > 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.
> > > > > > 
> > > > > > 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 it would be helpful to understand first whether there are users who would benefit.
> > > > > 
> > > > > For some reason I couldn’t see Randy’s 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’t write Rust code with capitalized variable and non-capitalized types. The Rust community is very much inclined to the standard style, AFAICT.
> > > > 
> > > > Yuan, did you make any progress here?
> > > 
> > > From what I can tell Randy isn’t very convince of this idea, so I didn’t make any changes. Randy, should we keep the status quo and close this or should we explore something else?
> > > 
> > > Yuan
> > 
> > Sorry for the late response.
> > 
> > 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’s what I proposed, yeah. You didn’t say “let’s do this” (maybe I missed it, apologies if I did), so obviously I didn’t want to jump the gun ;-)
> 
> > 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?
> 
> 
> 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 “feature” is a bit misleading in this regard...
> 
> Yuan

Sounds good, we can consider an option if anyone complains.
This is for master, right?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.