Closed OceanOak closed 2 months ago
[ ] Maybe in List <'a>
, DB<'a>
, and Dict<'a>
, the <'a>
should be tokenized as a typeParam instead of tokenizing <
, typeName
, >
separately.
[x] in Dict
maybe key
should be tokenized as a property instead of a string?
[ ] in EPipeEnum
, all of this is Stdlib.Result.Result.
is tokenized as a TypeName
instead of ModuleName.ModuleName.TypeName
. Same for EPipeFnCall
and MPEnum
[ ] maybe true
and false
shouldn't be tokenized as Keyword
Reason:
lets take this example: if true then true else false
the result of the semantic tokenization will be: Keyword Keyword Keyword Keyword Keyword Keyword
and it will be highlighted in the same color, which doesn't look right
(Maybe no one will write such code; it's just an example of an extreme case where everything would be
tokenized as a keyword.)
currently, we are not tokenizing the following:
.
s in fully qualified type name, function name, and constant name{}
and ;
in Type Declaration Record ;
in List=
and ;
in Dict ()
in PipeInfix and PipeLambdaThose are great comments - I added a link in #5259 to that comment so we don't lose track. Quick thoughts:
other
or constant
(depending on which tokenization system). adding a new token type for constant
might work well for us here. no 'default' available tokens fit super well, besides keyword, and the problem you outline is real
This PR fixes semantic tokenization, and adds tests for it