Dumb question, but I’m just moving over to VS Code from Atom. Is there a way to disable error squiggles with the elmtooling.elm-ls-vscode ???
This sounds crazy, but I find it SUPER distracting for there to be an “error” before I’ve even finished a thought! I get that once you hit save, you might want this. But it seems like constant negative reinforcement, like the way a grammar checker doesn’t check a sentence until you’ve finished typing the entire sentence!
E.g. there is nothing “error” about typing type alias Foo =, if you don’t compile the code! That is perfectly valid, and my brain is frizzing looking at the red & I’m second guessing myself.
Not a productive way to code!
I frankly can’t imagine why anyone would think this was clever. Early negative feedback is very mentally taxing–especially if it is incorrrect–and should be highly avoided!
I know this sounds minor, but if most people are now using VS Code, and this is their first experience with Elm… anyway, I guess I’m just saying that maybe this shouldn’t be the default behavior.
I’d tend to agree with you, especially since elm-format also kicks in on save, then you have both elm-format and the language server analysis at the same time. I personally don’t like this update on keystroke default for error display.
I really identify with @madasebrof’s experience, so I wonder if there are defaults that would work for a broader range of people.
For example:
Suppress red squiggles for a declaration if the cursor is present. (Maybe only triggering full compilation when transitioning between declarations, so maybe this could save some CPU and battery too!)
Suppress specific red squiggles for a declaration if the cursor is present. Maybe parser and canonicalization errors are suppressed, but show type errors. Or maybe even more fine-grained categorization would be ideal.
Maybe have a “distance from cursor” trigger? Maybe canonicalization errors show up, but only if they are on a different line than the cursor, or N tokens before the cursor. I can imagine this “distance from cursor” design would want slightly different settings for parse, canonicalization, and types.
@opvasger, as the red squiggle ambassador in the thread, would any of these approaches give you the kind of feedback you like?
For context, I do my programming on a single 14" screen. That means I tab a lot between windows.
The red squiggle is a visual hook, when I tab back into the text-editor. This is the only purpose I’m conscious of right now - there might be more subtleties to it I’m unconscious of.
I’d probably adjust my flow to save before tabbing, or hit enter in case of your 3rd example, or whatever keystroke it’ll take
Just continuing the grammar checker analogy, elm-format puts two blank lines between functions, types, etc.
If you want to leave it to default as a more active checker, maybe only trigger the parse checking after seeing two sequential blank lines before the cursor?
This, to me, is an indication that as a programmer you have “finished your thought” and would likewise not parse early on case foo of code, where you have a single empty line between cases.
I don’t think that’s the way to go. We can probably make it less distracting by adding a bit more debouncing, but early and good feedback (yes, we can improve here) is better then late feedback. Especially for newcomers or people that come from more developed tool ecosystems. Check the typescript behavior in vscode for e.g.
Your design would lead to people leaving a line, then seeing that there is an error and having to go back. So it might lead to rapid up/down arrow movements, just to get the linter to help you. That would mean, that we train a user to do this, which is bad. On top of this he also would need to discover that this is happening in the first place, so it’s secret and kind of random if they first discover it.
That being said, I can see, how this can be distracting to people that are more advanced and know what they are doing, but I would just suggest to setup your environment to run linting on save then.
Yeah, I guess it’s more a way of thinking philosophically about the goal of a linter (or a grammar checker).
In my mind, there is a difference between something being actually wrong, e.g.:
type aslias Foo =
Is an actually an error. There is no way to recover going forward. No matter what else I type next, my code won’t compile & I need to fix the typo.
vs.
type alias Foo =
Is just an incomplete thought. So maybe it’s more about the difference between those two concepts?
To me, it would be insane to have a grammar checker that, for example, underlined a sentence in red until I added the clause of the sentence (making the sentence grammatically correct). I would disable it immediately! And it’s not how Grammarly works. They check for spelling as you type (once you press the space bar), but wait until you “complete the thought” (press the period key) to check for grammatical errors.
The only reason I’m bringing this up at all is that I think it’s super important to think about default behavior, as now that VS Code is the default code editor for most folks in 2021 and elm-language–client is the only syntax highlighter for Elm for VS Code, most people from now on will have my exact experience.
And to me this was less than ideal, and worse that it was with Atom from a “productive coding” perspective and immediately and regular broke flow such that I stopped coding until i found a solution.
Again, @razze your call, you wrote the code! Just an n of one opinion.
I’m not sure comparing this with a grammar checker is healthy.
That being said, what’s the problem with the parser helping you (yes, we can’t do that right now)
type alias Foo =
Is an incomplete thought for you, but it might be an incomplete instruction for someone new to elm. What reason would there be to not help them and let the parser say something along the lines of
This statement seems incomplete, I'm looking for a { bracket
I also think invalid syntax and invalid code is an interesting distinction to trigger squiggles. Where the distinction is that invalid syntax cannot be recovered from (such as type aslias) while invalid code may be just incomplete code or not compiling code due to something different than syntax.
So unrecoverable invalid syntax could immediately trigger red squiggles, while incomplete or non-compiling code would “wait a little bit” to display the red squiggles. Then “wait a little bit” could default to save, cursor leaving area, whatever feels better default.
Also something interesting to mention. In rust analyzer, even though I don’t have the red squiggles immediately, when auto-completion does not show me what I’m expecting, I know something is fishy so I write a todo or similar valid syntax stuff, escape and look for that squiggle. Auto-completion in Elm is less useful since its functional while most functions calls are methods calls in Rust, making auto completion easier and more useful.
Not to be pedantic, but I don’t get the design goal of telling someone who is new to a programming language that there is an error before they have a chance to correct it!
Mentally, that is very taxing! Imagine if you were having a conversation with someone, as as you were talking they were shaking their head no, no, no until you finished your sentence, and only then did they nod their head yes! It would make it very difficult to communicate! The entire time you were talking, you’d be second-guessing yourself.
My point is that is it is MUCH WORSE to give someone immediate, incorrect negative feedback than to give no feedback at all. Not only is it worse, but it is also paralyzing and mentally taxing–the last things you’d want to have in a coding environment!
I’m just not sure the use case the current behavior is designed for, and I honestly think it’s trying to solve a problem that doesn’t exist. (The compiler will point out errors in a thoughtful way.)
The only reason I’m bringing this all up is that the behavior of elm-language-client will affect the vast majority of new Elm users worldwide, and therefore, I think it’s worth really thinking about.
Or put another way @evancz, it’s worth downloading a fresh build of VS Code, typing “Elm” in the library search bar, install the recommended tools, and seeing if you would be happy coding in that environment, or if you would immediately do what I did, e.g. disable code lensing (so there aren’t these odd inline function explainer in the code), change to linting to on save only (note–there is no way to disable entirely), etc.
I’ve pondered this more, and experimented while coding. The immediate feedback helps me move faster - The suggestions I’ve seen (even @razze’s suggestion to debounce for longer) seems like instances of waiting longer for feedback - but I really enjoy how fast it is (thanks @razze!!)
Visual noise?
@madasebrof, let’s say you still get the feedback, but perhaps in a less visually taxing way than red squiggles? Can you imagine a version of the current behaviour that visually doesn’t feel bad or stressful to look at? You obviously aren’t forced to deal with the red squiggly stuff first, but I understand how it can feel that way, and perhaps another visual indication could strike a balance between “guiding my eyes” and “not shouting ERROR at you”
I experimented with a dev-server once, that pushed new code over websockets when changes were made. When the compiler found errors, I had it overwrite the html-document in the browser with a full-screen compiler-message. The idea seemed pretty great at the time. Before seeing it play out, I made the background red, and overlayed it with the error-message in a nice white font.
…
Using it, I quickly got really stressed out by the sharp red color blowing up in my face everytime I hit save a bit too quick or made some typos. I immediately refactored to a soft blue background-color, and had a much better time.
Maybe just a separate “this doesn’t seem to be finished yet” color of some sort that is sensitive to the location of the cursor like @evancz was saying. So you can still tell it’s invalid but it makes a distinction between “invalid because you wrote it wrong” and “invalid because you’re not done”
Now imagine getting stuck, while you talk and the other side helping you finish your sentence, would you rather have to switch to your phone and look up what you were thinking about?
Anyway, while thinking about this is fun, I don’t think anybody will spend time working on it. I feel like there are many places where we can achieve bigger, less controversial gains.
Ahhh. I get it. in your mind, the “error” is helpful!
Funny, I don’t see this as being controversial. I viewed it more like something someone made because “they could” and they thought it was cool, but maybe didn’t actively think through the consequences.
You’re saying that you thought about it beforehand and like this behavior and coded it this way on purpose. And seeing bright red squiggles under valid code as you type doesn’t bother you–in fact, it’s a good thing–because in your mind you know that eventually, the red squiggles will go away once you complete the function/type/etc.
It’s like “away from” motivated coding!
Fair enough. Obviously, this not how my brain works. For me, I like to mentally separate “building coding” from “debugging coding”. So in my mind, it’s more like I was pointing out a bug.
But hey, to each his own!
re: another way of doing this that is less stressful. Not sure if there is a way to just color the gutter white or something. For example, the way Desmos, the graphing calculator works, is that the icon next to the field indicates the formula is not valid yet (ps it doesn’t turn red). And doesn’t affect the actual equation text you are working on in any way.
Anyway, sorry to make this thread go on for so long. I’m not usually an online ranter. It’s more just that I know if this throws me off, chances are it’s going throw a lot of other people off.
If you decide to change the defaults to hide lensing and only lint on save, great. If not, what can you do.
We do have some more options, due to the language server protocol we’re using we also have Warning, so it would be yellow. Info which get’s blue squgglies and Hint which shows three dots.
Hint is also special, as it does not show up in the problems panel.
However, it might be labor intensive to fine tune when to show an error and when to show something different.
As @madasebrof I just wanted to voice some concern, but get that different people react differently to this. Also, even though I disagree on this point, I’m very much grateful of the work you’ve done on the language server @razze. It’s getting better and more useful thanks to Jon and you. And I’d encourage anyone benefiting from this to help supporting them. You can sponsor them individually on GitHub, or via their elm-tooling OpenCollective.
Personally, I much prefer the lint-on-save approach as it gives me control over when ‘my thought has finished’. And the Cmd-S muscle memory means this is intimately bound with my programming thought process. This works especially well in combination with elm-format (on save) where I will deliberately use a non-elm-format layout as I type and then look to see if layout is corrected on save. That way I get immediate visual feedback on passing the syntax check as distinct from other “red-squiggle” errors. After saving, I would want all red-squiggle errors to appear, even (and especially) those immediately in the vicinity of the cursor.
