* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
@ 2024-03-08 4:43 Yuan Fu
2024-03-08 22:56 ` Dmitry Gutov
2024-03-09 3:50 ` Randy Taylor
0 siblings, 2 replies; 16+ messages in thread
From: Yuan Fu @ 2024-03-08 4:43 UTC (permalink / raw
To: 69625
X-Debug-CC: dev@rjt.dev <mailto:dev@rjt.dev>
(I lied a little bit about on the [PATCH] part: I have a solution but didn’t turn it into a patch yet.)
The problem is follows: given the rust code below, some enum are not fontified with type face under font lock level 3, and those enum are fontified as function or variable under font lock level 4.
fn main() {
func(MyEnum::VariantA(0));
func(MyEnum::VariantB);
func(VariantC);
func(VariantD(0));
}
VariantA and VariantB are fontified correctly, but VariantC and VariantD are not.
I think a simple rule that fontifies every capitalized identifier would fix this. But I don’t know if that’ll create other problem. AFAIK capitalized identifier is always some type in rust, right?
This is first reported on rust-mode’s GitHub repo: https://github.com/rust-lang/rust-mode/issues/518
Yuan
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-03-08 4:43 bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum Yuan Fu
@ 2024-03-08 22:56 ` Dmitry Gutov
2024-03-09 3:50 ` Randy Taylor
1 sibling, 0 replies; 16+ messages in thread
From: Dmitry Gutov @ 2024-03-08 22:56 UTC (permalink / raw
To: Yuan Fu, 69625
On 08/03/2024 06:43, Yuan Fu wrote:
> The problem is follows: given the rust code below, some enum are not
> fontified with type face under font lock level 3, and those enum are
> fontified as function or variable under font lock level 4.
>
> fn main() {
> func(MyEnum::VariantA(0));
> func(MyEnum::VariantB);
> func(VariantC);
> func(VariantD(0));
> }
>
> VariantA and VariantB are fontified correctly, but VariantC and VariantD
> are not.
>
> I think a simple rule that fontifies every capitalized identifier would
> fix this. But I don’t know if that’ll create other problem. AFAIK
> capitalized identifier is always some type in rust, right?
This might be more of an issue with highlighters order. As you can see,
level 3 fontifies these as 'type' already, and does that because the
identifiers are capitalized.
Some level 4 rules probably either come earlier than where they should
be (thus applying before the ones with the "capitalized" matcher), or
they should use a "not capitalized" matcher if moving them down would
cause other problems.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-03-08 4:43 bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum Yuan Fu
2024-03-08 22:56 ` Dmitry Gutov
@ 2024-03-09 3:50 ` Randy Taylor
2024-03-15 1:52 ` Dmitry Gutov
1 sibling, 1 reply; 16+ messages in thread
From: Randy Taylor @ 2024-03-09 3:50 UTC (permalink / raw
To: Yuan Fu; +Cc: Dmitry Gutov, 69625
On Thursday, March 7th, 2024 at 23:43, Yuan Fu <casouri@gmail.com> wrote:
>
> X-Debug-CC: dev@rjt.dev mailto:dev@rjt.dev
Should be X-Debbugs-CC ;).
>
>
> (I lied a little bit about on the [PATCH] part: I have a solution but didn’t turn it into a patch yet.)
>
> The problem is follows: given the rust code below, some enum are not fontified with type face under font lock level 3, and those enum are fontified as function or variable under font lock level 4.
>
> fn main() {
> func(MyEnum::VariantA(0));
> func(MyEnum::VariantB);
> func(VariantC);
> func(VariantD(0));
> }
>
> VariantA and VariantB are fontified correctly, but VariantC and VariantD are not.
>
> I think a simple rule that fontifies every capitalized identifier would fix this. But I don’t know if that’ll create other problem. AFAIK capitalized identifier is always some type in rust, right?
>
For VariantA and VariantD, these are constructors being used as functions,
so I think they are technically being highlighted correctly at level 4.
Whether or not that is desired is another question - I think that is simply
a matter of opinion/preference.
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?
I'm not sure how worth it would be to do something about that though, or how
easy.
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.
I don't really think this is a tree-sitter problem to solve but more so an LSP one:
tree-sitter can't know that all of these are enums based on how they are used.
As was mentioned in that GitHub thread, LSP with semantic tokens is the way to go
for the most accuracy. But even with semantic tokens, how to highlight enum variants
being used as functions comes down to opinion methinks.
> This is first reported on rust-mode’s GitHub repo: https://github.com/rust-lang/rust-mode/issues/518
>
> Yuan
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-03-09 3:50 ` Randy Taylor
@ 2024-03-15 1:52 ` Dmitry Gutov
2024-03-16 1:37 ` Randy Taylor
2024-04-08 7:25 ` Yuan Fu
0 siblings, 2 replies; 16+ messages in thread
From: Dmitry Gutov @ 2024-03-15 1:52 UTC (permalink / raw
To: Randy Taylor, Yuan Fu; +Cc: 69625
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-03-15 1:52 ` Dmitry Gutov
@ 2024-03-16 1:37 ` Randy Taylor
2024-04-08 7:25 ` Yuan Fu
1 sibling, 0 replies; 16+ messages in thread
From: Randy Taylor @ 2024-03-16 1:37 UTC (permalink / raw
To: Dmitry Gutov; +Cc: Yuan Fu, 69625
On Thursday, March 14th, 2024 at 21:52, Dmitry Gutov <dmitry@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.
>
Indeed, but those rules (minus the ALL_CAPS one) don't apply to all
identifiers but rather specific kinds (most if not all applying to
use declarations).
> 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.
Agreed. This is the first I've heard it mentioned.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-03-15 1:52 ` Dmitry Gutov
2024-03-16 1:37 ` Randy Taylor
@ 2024-04-08 7:25 ` Yuan Fu
2024-06-22 11:07 ` Stefan Kangas
1 sibling, 1 reply; 16+ messages in thread
From: Yuan Fu @ 2024-04-08 7:25 UTC (permalink / raw
To: Dmitry Gutov; +Cc: Randy Taylor, 69625
> On Mar 14, 2024, at 6:52 PM, Dmitry Gutov <dmitry@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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-04-08 7:25 ` Yuan Fu
@ 2024-06-22 11:07 ` Stefan Kangas
2024-06-22 23:17 ` Yuan Fu
0 siblings, 1 reply; 16+ messages in thread
From: Stefan Kangas @ 2024-06-22 11:07 UTC (permalink / raw
To: Yuan Fu, Dmitry Gutov; +Cc: Randy Taylor, 69625
Yuan Fu <casouri@gmail.com> writes:
>> On Mar 14, 2024, at 6:52 PM, Dmitry Gutov <dmitry@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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-06-22 11:07 ` Stefan Kangas
@ 2024-06-22 23:17 ` Yuan Fu
2024-06-28 2:40 ` Randy Taylor
0 siblings, 1 reply; 16+ messages in thread
From: Yuan Fu @ 2024-06-22 23:17 UTC (permalink / raw
To: Stefan Kangas; +Cc: Dmitry Gutov, 69625, Randy Taylor
> On Jun 22, 2024, at 4:07 AM, Stefan Kangas <stefankangas@gmail.com> wrote:
>
> Yuan Fu <casouri@gmail.com> writes:
>
>>> On Mar 14, 2024, at 6:52 PM, Dmitry Gutov <dmitry@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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-06-22 23:17 ` Yuan Fu
@ 2024-06-28 2:40 ` Randy Taylor
2024-06-28 4:43 ` Yuan Fu
0 siblings, 1 reply; 16+ messages in thread
From: Randy Taylor @ 2024-06-28 2:40 UTC (permalink / raw
To: Yuan Fu; +Cc: Dmitry Gutov, Stefan Kangas, 69625
On Saturday, June 22nd, 2024 at 19:17, Yuan Fu <casouri@gmail.com> wrote:
>
>
>
>
> > On Jun 22, 2024, at 4:07 AM, Stefan Kangas stefankangas@gmail.com wrote:
> >
> > Yuan Fu casouri@gmail.com writes:
> >
> > > > On Mar 14, 2024, at 6:52 PM, Dmitry Gutov dmitry@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.
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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-06-28 2:40 ` Randy Taylor
@ 2024-06-28 4:43 ` Yuan Fu
2024-06-29 2:37 ` Randy Taylor
0 siblings, 1 reply; 16+ messages in thread
From: Yuan Fu @ 2024-06-28 4:43 UTC (permalink / raw
To: Randy Taylor; +Cc: Dmitry Gutov, Stefan Kangas, 69625
> On Jun 27, 2024, at 7:40 PM, Randy Taylor <dev@rjt.dev> wrote:
>
> On Saturday, June 22nd, 2024 at 19:17, Yuan Fu <casouri@gmail.com> wrote:
>>
>>
>>
>>
>>> On Jun 22, 2024, at 4:07 AM, Stefan Kangas stefankangas@gmail.com wrote:
>>>
>>> Yuan Fu casouri@gmail.com writes:
>>>
>>>>> On Mar 14, 2024, at 6:52 PM, Dmitry Gutov dmitry@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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-06-28 4:43 ` Yuan Fu
@ 2024-06-29 2:37 ` Randy Taylor
2024-06-29 3:03 ` Stefan Kangas
0 siblings, 1 reply; 16+ messages in thread
From: Randy Taylor @ 2024-06-29 2:37 UTC (permalink / raw
To: Yuan Fu; +Cc: Dmitry Gutov, Stefan Kangas, 69625
On Friday, June 28th, 2024 at 00:43, Yuan Fu <casouri@gmail.com> wrote:
>
> > On Jun 27, 2024, at 7:40 PM, Randy Taylor dev@rjt.dev wrote:
> >
> > On Saturday, June 22nd, 2024 at 19:17, Yuan Fu casouri@gmail.com wrote:
> >
> > > > On Jun 22, 2024, at 4:07 AM, Stefan Kangas stefankangas@gmail.com wrote:
> > > >
> > > > Yuan Fu casouri@gmail.com writes:
> > > >
> > > > > > On Mar 14, 2024, at 6:52 PM, Dmitry Gutov dmitry@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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-06-29 2:37 ` Randy Taylor
@ 2024-06-29 3:03 ` Stefan Kangas
2024-06-29 5:41 ` Yuan Fu
0 siblings, 1 reply; 16+ messages in thread
From: Stefan Kangas @ 2024-06-29 3:03 UTC (permalink / raw
To: Randy Taylor, Yuan Fu; +Cc: Dmitry Gutov, 69625
Randy Taylor <dev@rjt.dev> writes:
> Sounds good, we can consider an option if anyone complains.
> This is for master, right?
Yeah, it's probably too late for Emacs 30.
That said, if the patch is very small and/or trivial, and well-tested,
we sometimes make exceptions for important changes. I have no idea if
any of that would apply here, so I'm mentioning it for completion.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-06-29 3:03 ` Stefan Kangas
@ 2024-06-29 5:41 ` Yuan Fu
2024-06-29 19:08 ` Randy Taylor
0 siblings, 1 reply; 16+ messages in thread
From: Yuan Fu @ 2024-06-29 5:41 UTC (permalink / raw
To: Stefan Kangas; +Cc: Randy Taylor, 69625, Dmitry Gutov
> On Jun 28, 2024, at 8:03 PM, Stefan Kangas <stefankangas@gmail.com> wrote:
>
> Randy Taylor <dev@rjt.dev> writes:
>
>> Sounds good, we can consider an option if anyone complains.
>> This is for master, right?
>
> Yeah, it's probably too late for Emacs 30.
>
> That said, if the patch is very small and/or trivial, and well-tested,
> we sometimes make exceptions for important changes. I have no idea if
> any of that would apply here, so I'm mentioning it for completion.
I would apply it to master. So that people on master would have time to complain, if ever.
Yuan
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-06-29 5:41 ` Yuan Fu
@ 2024-06-29 19:08 ` Randy Taylor
2024-07-06 8:05 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Randy Taylor @ 2024-06-29 19:08 UTC (permalink / raw
To: Yuan Fu; +Cc: Dmitry Gutov, Stefan Kangas, 69625
On Saturday, June 29th, 2024 at 01:41, Yuan Fu <casouri@gmail.com> wrote:
>
>
> > On Jun 28, 2024, at 8:03 PM, Stefan Kangas stefankangas@gmail.com wrote:
> >
> > Randy Taylor dev@rjt.dev writes:
> >
> > > Sounds good, we can consider an option if anyone complains.
> > > This is for master, right?
> >
> > Yeah, it's probably too late for Emacs 30.
> >
> > That said, if the patch is very small and/or trivial, and well-tested,
> > we sometimes make exceptions for important changes. I have no idea if
> > any of that would apply here, so I'm mentioning it for completion.
>
>
> I would apply it to master. So that people on master would have time to complain, if ever.
>
> Yuan
We're on the same wavelength :).
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-06-29 19:08 ` Randy Taylor
@ 2024-07-06 8:05 ` Eli Zaretskii
2024-07-06 21:10 ` Yuan Fu
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2024-07-06 8:05 UTC (permalink / raw
To: Randy Taylor; +Cc: dmitry, casouri, stefankangas, 69625
> Cc: Dmitry Gutov <dmitry@gutov.dev>, Stefan Kangas <stefankangas@gmail.com>,
> 69625@debbugs.gnu.org
> Date: Sat, 29 Jun 2024 19:08:47 +0000
> From: Randy Taylor <dev@rjt.dev>
>
> On Saturday, June 29th, 2024 at 01:41, Yuan Fu <casouri@gmail.com> wrote:
> >
> >
> > > On Jun 28, 2024, at 8:03 PM, Stefan Kangas stefankangas@gmail.com wrote:
> > >
> > > Randy Taylor dev@rjt.dev writes:
> > >
> > > > Sounds good, we can consider an option if anyone complains.
> > > > This is for master, right?
> > >
> > > Yeah, it's probably too late for Emacs 30.
> > >
> > > That said, if the patch is very small and/or trivial, and well-tested,
> > > we sometimes make exceptions for important changes. I have no idea if
> > > any of that would apply here, so I'm mentioning it for completion.
> >
> >
> > I would apply it to master. So that people on master would have time to complain, if ever.
> >
> > Yuan
>
> We're on the same wavelength :).
Ping! Can we complete this by installing the patch, please?
I don't see any patches in this discussion. If someone knows what is
the patch, please either post it here or install on master.
Thanks.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum
2024-07-06 8:05 ` Eli Zaretskii
@ 2024-07-06 21:10 ` Yuan Fu
0 siblings, 0 replies; 16+ messages in thread
From: Yuan Fu @ 2024-07-06 21:10 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Randy Taylor, 69625-done, Stefan Kangas, Dmitry Gutov
> On Jul 6, 2024, at 1:05 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> Cc: Dmitry Gutov <dmitry@gutov.dev>, Stefan Kangas <stefankangas@gmail.com>,
>> 69625@debbugs.gnu.org
>> Date: Sat, 29 Jun 2024 19:08:47 +0000
>> From: Randy Taylor <dev@rjt.dev>
>>
>> On Saturday, June 29th, 2024 at 01:41, Yuan Fu <casouri@gmail.com> wrote:
>>>
>>>
>>>> On Jun 28, 2024, at 8:03 PM, Stefan Kangas stefankangas@gmail.com wrote:
>>>>
>>>> Randy Taylor dev@rjt.dev writes:
>>>>
>>>>> Sounds good, we can consider an option if anyone complains.
>>>>> This is for master, right?
>>>>
>>>> Yeah, it's probably too late for Emacs 30.
>>>>
>>>> That said, if the patch is very small and/or trivial, and well-tested,
>>>> we sometimes make exceptions for important changes. I have no idea if
>>>> any of that would apply here, so I'm mentioning it for completion.
>>>
>>>
>>> I would apply it to master. So that people on master would have time to complain, if ever.
>>>
>>> Yuan
>>
>> We're on the same wavelength :).
>
> Ping! Can we complete this by installing the patch, please?
>
> I don't see any patches in this discussion. If someone knows what is
> the patch, please either post it here or install on master.
>
> Thanks.
I installed 2e9777512a0 to master.
Yuan
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2024-07-06 21:10 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-08 4:43 bug#69625: 30.0.50; [PATCH] rust-ts-mode doesn't fontify some enum Yuan Fu
2024-03-08 22:56 ` Dmitry Gutov
2024-03-09 3:50 ` Randy Taylor
2024-03-15 1:52 ` Dmitry Gutov
2024-03-16 1:37 ` Randy Taylor
2024-04-08 7:25 ` Yuan Fu
2024-06-22 11:07 ` Stefan Kangas
2024-06-22 23:17 ` Yuan Fu
2024-06-28 2:40 ` Randy Taylor
2024-06-28 4:43 ` Yuan Fu
2024-06-29 2:37 ` Randy Taylor
2024-06-29 3:03 ` Stefan Kangas
2024-06-29 5:41 ` Yuan Fu
2024-06-29 19:08 ` Randy Taylor
2024-07-06 8:05 ` Eli Zaretskii
2024-07-06 21:10 ` Yuan Fu
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.