When displaying a lint in the "Problems" panel it would be helpful to show the name of the lint. This would make ignoring the lint with the // ignore: comment easier.
Hmm, this is kinda annoying - we pass the code through to Code but it doesn't get displayed. The API is annotated with:
/**
* A code or identifier for this diagnostics. Will not be surfaced
* to the user, but should be used for later processing, e.g. when
* providing [code actions](#CodeActionContext).
*/
code: string | number;
So it seems like they deliberately decided not to show error codes to users. We can jam them into the message, but it would've been nice if Code had a column for them.
Putting them on the end in brackets looks weird (because the messages end with fullstops). Putting them at the start still looks weird, but might be the best we can do.
WDYT?

diff --git a/src/providers/dart_diagnostic_provider.ts b/src/providers/dart_diagnostic_provider.ts
index 8a04871..ac280ad 100644
--- a/src/providers/dart_diagnostic_provider.ts
+++ b/src/providers/dart_diagnostic_provider.ts
@@ -32,7 +32,7 @@ export class DartDiagnosticProvider {
private createDiagnostic(error: as.AnalysisError): Diagnostic {
return {
code: error.code,
- message: error.message,
+ message: (error.type == "LINT" ? `${error.code}: ` : "") + error.message,
range: toRange(error.location),
severity: this.getSeverity(error.severity),
source: "dart"
Yeah putting the lint name before the message looks good to me. I _think_ that's what the Atom plugin does.
If anything, you could put the lint name display behind an option, so that it's only there if you want it to be there.
@Skylled That's a good point, not everyone cares about the name. And even if you do, you might not care about it all the time
Yeah, seems like a reasonable idea. I'm not a fan of too many options (increases testing burden) but this is a pretty trivial change in behaviour!
Hoping to get some time to work on DC over the weekend, so will get this in for 2.1.
But, if anyone is looking for something to get their toes wet in the meantime, this would be a pretty easy first contribution! I included a diff above that turned it on always; all that's needed is a new property adding to the config class (there are loads to copy) and then config.xxx adding to the condition above! (Oh, and the option adding to packages.config for the intellisense and the readme for an explanation).
The contributing file was updated recently with a little more info on how it works and how to run it.
(Note: I'm not trying to fob this off, I just don't know if people would like to contribute but don't know where to start! :-))
I've made an additional tweak to this so that you don't need to reload the project after changing this setting; it'll automatically re-analyze (similar to we do when TODO setting changes). Probably this isn't as efficient as it could be (since we already know the errors and we're asking the analyzer to scan again) but it's simple and avoids it looking like this setting isn't working.