You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Syntax highlighting colours function names differently when starting with capital #311
That's the convention; but you don't have to follow it. If we were using the data from the analyzer, I'd expect they would be coloured correctly (based on actual AST, not guesses based on casing) so ideally we should be the same (whether it's reasonable or worthwhile, I don't know.. maybe we should just hope for microsoft/vscode#1967!)
Looking at this again on a whim, maybe we could assume that any ambiguous capitalized object that is followed by parens but not preceded by new or const is a function.
class IsClass {}
void NotClass(){}
var x = new IsClass();
var y = NotClass();
But that still won't help when assigning a function to a variable.
someObj.callback = NotClass // There's nothing here to detect from.
Additionally, the inverse problem is also true, lowerCamelCase class names are not treated correctly.
class alsoAClass {} // No colorizing
var z = new alsoAClass(); // Colored as a function
Seems like the best solution would be to get direct from the AST, as you said.
I think using the parens is probably the best way; seems more reliable than guessing based on case. I don't think Code is going to support dynamic colouring anytime soon :(
I'll see if I can change the regex at some point to handle this better.
Found another case where upper case is tripping up the syntax highlighting:
class FileMode {
/// The mode for opening a file only for reading.
static const read = const FileMode._internal(0); @deprecated("Use read instead")
static const READ = read;
...
In this snippet lower case read is scoped as source.dart but upper case READ is scoped as support.class.
@weenzeel thanks for the example. It's hard (for me) to fix some of these issues with the textmate grammar. I did hope to try and generate it from the language descriptions (in the hope it'd be accurate, including fixing the comment-highlighting bugs that keep coming up) - see dart-lang/sdk#19298, but so far I haven't found a good way.
@DanTup I opened a syntax issue with Jetbrains and Dart SDK earlier this year. Feedback from Jetbrains was that they depended on the Analysis Server for Dart syntax highlighting. Not sure how that works or viable for VSC as well?
I have seen a workaround someone made that uses the VS Code decorations API to provide the colours - it's an interesting idea, but I haven't dug into how feasible (or reliably) it would be here.
tbh if you left it the way it is, i think it's fine. Typescript tooling is unopinionated, but Dart tooling is typically very opinionated. Just my opinion. 😄
This will be handled as part of #2202. It works using the semantic tokens and LSP, but the API hasn't been finalised in LSP so we can't finish/release it yet.
In order to get the fix you'll need Dart-Code v3.18.0 (a preview release should be available later today/tomorrow), be using LSP Preview, and have a Dart SDK from after yesterday (the most recent nightly works, and of course the next releases of Dart/Flutter SDKs will include this).
Due to some last minute issues, support for LSP 3.16 (which supports semantic tokens) won't be included in v3.18, but hopefully v3.19 next month instead.
Activity
Skylled commentedon May 25, 2017
Isn't this because capitalization implies a Class name instead of a function?
DanTup commentedon May 25, 2017
That's the convention; but you don't have to follow it. If we were using the data from the analyzer, I'd expect they would be coloured correctly (based on actual AST, not guesses based on casing) so ideally we should be the same (whether it's reasonable or worthwhile, I don't know.. maybe we should just hope for microsoft/vscode#1967!)
Skylled commentedon Jul 23, 2017
Looking at this again on a whim, maybe we could assume that any ambiguous capitalized object that is followed by parens but not preceded by
neworconstis a function.But that still won't help when assigning a function to a variable.
Additionally, the inverse problem is also true, lowerCamelCase class names are not treated correctly.
Seems like the best solution would be to get direct from the AST, as you said.
DanTup commentedon Jul 24, 2017
I think using the parens is probably the best way; seems more reliable than guessing based on case. I don't think Code is going to support dynamic colouring anytime soon :(
I'll see if I can change the regex at some point to handle this better.
weenzeel commentedon Jun 16, 2019
Found another case where upper case is tripping up the syntax highlighting:
class FileMode {
/// The mode for opening a file only for reading.
static const read = const FileMode._internal(0);
@deprecated("Use read instead")
static const READ = read;
...
In this snippet lower case read is scoped as source.dart but upper case READ is scoped as support.class.
DanTup commentedon Jun 17, 2019
@weenzeel thanks for the example. It's hard (for me) to fix some of these issues with the textmate grammar. I did hope to try and generate it from the language descriptions (in the hope it'd be accurate, including fixing the comment-highlighting bugs that keep coming up) - see dart-lang/sdk#19298, but so far I haven't found a good way.
weenzeel commentedon Jun 17, 2019
@DanTup I opened a syntax issue with Jetbrains and Dart SDK earlier this year. Feedback from Jetbrains was that they depended on the Analysis Server for Dart syntax highlighting. Not sure how that works or viable for VSC as well?
dart-lang/sdk#35679
DanTup commentedon Jun 17, 2019
The Dart server provides this info, but VS Code doesn't allow extensions to perform colouring programtically:
microsoft/vscode#585
I have seen a workaround someone made that uses the VS Code decorations API to provide the colours - it's an interesting idea, but I haven't dug into how feasible (or reliably) it would be here.
lukepighetti commentedon Dec 11, 2019
tbh if you left it the way it is, i think it's fine. Typescript tooling is unopinionated, but Dart tooling is typically very opinionated. Just my opinion. 😄
2 remaining items
DanTup commentedon Oct 27, 2020
This will be handled as part of #2202. It works using the semantic tokens and LSP, but the API hasn't been finalised in LSP so we can't finish/release it yet.
DanTup commentedon Dec 15, 2020
Fixed by dart-lang/sdk@cb2ede5.
In order to get the fix you'll need Dart-Code v3.18.0 (a preview release should be available later today/tomorrow), be using LSP Preview, and have a Dart SDK from after yesterday (the most recent nightly works, and of course the next releases of Dart/Flutter SDKs will include this).
DanTup commentedon Dec 22, 2020
Due to some last minute issues, support for LSP 3.16 (which supports semantic tokens) won't be included in v3.18, but hopefully v3.19 next month instead.