The default vscode user experience is to show red squiggles when typing, and if you don’t like them you have to go out of your way to change the behavior.
If you search for “save” on settings, many language plugins have a “update diagnostics on save” or similar, like the Elm plugin has.
I think the issue here is your mismatched expectations with how vscode works and what you want, and the Elm plugin is already doing the right thing by having a toggle to only do it on save.
Making that toggle the default, would go against what vscode does as an editor, breaking expectations of the vscode’s users.
Very dramatic title by the way, all words capitalized, calling real errors false when they are real, and using multiple punctuation marks…
I really enjoy seeing this errors before I save.
Hot module reload does not work when you get a compile error? You have to fix the error, save again and it starts with a fresh new state.
The red errors before save is great! It prevents me from doing a save and loose state . I do not want to manual do unnecessary clicking into the wanted state after fix just because of a typo…
Changed title to be less dramatic but I stand by the concept–they are not “real errors” any more than an incomplete sentence is a “real error” while you are in the middle of typing it.
(I get that it’s much more work for the linter to understand the difference between an actual error that is unrecoverable vs. an incomplete statement.)
For C# in VS2019 the squiggle is displayed after the equals sign:
But in VS Code it is displayed directly on the equals sign. Is this a limitation of VS Code?
If you save the file with the incomplete type alias the elm compiler only reports the place after the equals sign and says it expects something at this place. Also VS Code shows it here on the equals sign.
While the Elm Language Server marks everything and just says parsing error. Maybe it is enough to improve the squiggle regions when still unsaved? I expect that the syntax tree is not capable of representing incomplete syntax.
The C# Syntax Tree contains at this position an IdentifierName-SyntaxNode with IsMissing set on true. I expect the Syntax Tree of the Elm Language Server does not have something like this.
In my opinion the problem is the region where the squiggle is displayed and not that it should wait until it is completed. This must be implemented for every language construct. Right now these constructs comes to my mind: type, type alias, constants/functions in module and let. There could be more places where the syntax tree should represent incomplete syntax.
As to the head shaking anology. Having the squiggle on the end could be interpreted as “I’m still listening.”. In this case it should solve the problem? There could be problems that this is hard to see for some people. In my case this would be just fine, because it is already the case in C# for years. And if i do not see it in the code after a compilation error, then i just click on the entry in the error list or click on the scrollbar where the red dot is displayed.
Honestly, this makes total sense to me, because it is telling you that you need to type more to make a complete, compilable chunk of code, not that what you’ve previously typed is wrong. I also get that it’s a lot more work!
intellij-elm also shows just a small red squiggly after the = in type alias Foo =. In general, it seems to highlight a very small portion exactly where (it considers) the syntax error is. That’s really nice!
Another thing that helps in intellij is that unresolved variables (misspelled, not defined yet, not imported yet) are not underlined with squiggles. Instead, they are in bold and red font – that’s not as “screaming” as squiggles.
Actually, it’s pretty nice to easily see the difference between different kinds of errors at a glance:
Syntax error: Small squiggly at a very specific place
Unresolved reference: Bold and red
Type error: Big squiggly around a full expression
Maybe the VSCode extension can steal some of that!
(I like errors as I type, but sometimes it gets annoying when a very big expression gets squigglified and the whole screen is red I sometimes do tricks like adding |> x at the end temporarily, so that the error switches to just highlighting x as undefined.)
I don’t think so, if there is a whitespace we can highlight it. But we can’t highlight in spaces where there is no text.
I also think that’s the cause for most of this and would be preferable. The syntax tree we’re using can has special error and missing nodes. But I haven’t spend much time on the unhappy path for it. So this example:
Maybe this is as simple as just don’t make it the bright red so in-your-face that it is. It is actually hard to focus on the text when an entire huge update function is highlighted because you happen to be working on a part of it. Perhaps simply lighten the colour down a few levels…
but I stand by the concept–they are not “real errors” any more than an incomplete sentence is a “real error” while you are in the middle of typing it.
I sometimes do tricks like adding