[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
From: |
Dmitry Gutov |
Subject: |
bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum |
Date: |
Fri, 15 Mar 2024 03:52:38 +0200 |
User-agent: |
Mozilla Thunderbird |
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.