I'd like to add a way to opt out of individual diagnostics (since the "mismatched arg count" has a couple of false positives), and was thinking that we might want to have a more granular way to configure severity of diagnostics.
I see that the default CSS plugin allows configuring various lint levels, maybe we want to have the same? Perhaps not on a per-diagnostic level, but I think it would be nice to have individual opt-outs for things like missing match arms (which also occasionally gives false positives) and other diagnostics. Thoughts?
If we don't want this, I'd just add a "Enable Experimental Diagnostics" toggle instead that turns off diagnostics with many false positives.
Maybe "experimental" should include
MissingOkInTailExpr, since that's just a limited mismatched types diagnostics and I've seen an issue about false positives for that one too
I think we might want both -- I think a "enable experimental diagnostics" toggle would be a good idea so we can introduce more of them and not have people need to toggle each of them off separately, but also configuring specific diagnostics would be good (though long term that should happen through attributes)
Attributes as in
maybe we could even have levels of experimental diagnostics, so we could have a super spammy level where we give a diagnostic for every type mismatch (though I might be the only person who enables that :sweat_smile: )
That sounds like a good fit for hints and warnings, but maybe not for error diagnostics
hm that's true
ok, long-term error diagnostics should be perfect anyway ;)
so, a general toggle seems more important and useful to me right now
OTOH maybe we want people to have to disable each diagnostic separately...
I kinda do :)
well... I kind of want to have a place for super-experimental diagnostics, and then have them graduate to a default-on state where people can still disable them. I think it's useful if you can add a diagnostic in a not-yet-ready-for-general-consumption state
I guess that would be possible with specific toggles as well though
soo yeah, maybe individual toggles are the better approach after all :sweat_smile:
If we change the default setting, will that update within VS Code or will the old default be kept?
I think we can implement defaults on server side that apply if the setting hasn't been explicitly set by the user?
Oh, yeah, we already have that
But the plugin-side also has defaults, maybe they're optional though
yeah I don't know how those work
In the stupidest way possible
Even if the user has nothing in their settings, VS Code will gladly stomp over every server default
But I don't think unsynced defaults are a big problem
well, actually the Emacs impl will kind of do the same
Like, they'll converge eventually
maybe we want to model this as two settings "disabled diagnostics" and "enabled experimental diagnostics" that are just lists of strings anyway?
Yeah, this seems like the best solution
Well, impl-wise, for every diagnostic we should have either "on" or "off", without distinguishing experimental from non-experimental ones
but two lists in the UI seem good!
Hmm, can we accept an arbitrary string-keyed map as a setting? Then each diagnostic can be mapped to a severity instead of just turned on or off.
Like, having a general type mismatch diagnostic that emits errors would be too noisy, but not necessarily if it's only at hint level
And when users turn it off completely, they miss out on quick fixes
initialization options are
any, so... I guess?
that would also make it just one map instead of two lists, which is nice
well, I guess it's possible that VSCode doesn't allow arbitrary JSON as settings, I can't speak to that
Yup, map would be fien
Can you provide custom settings UI or would this just be a JSON entry box for users? :D
I think it'll be JSON
Seems fine by me
we are not going to have many false positives, are we? :D
I meant this to also be the way to configure warnings and hints, and for those a nicer UI would be good
package.json needs to be produced by xtask
I'll just go with the experimental diagnostics checkbox for now. Is there a way to invalidate existing diagnostics when the box is (un)checked?
sudo reboot? I'd punt on this for the time being
I could maybe add it to